Implementing Data-Driven Networking has significant challenges if we are going to successfully acquire the wealth of data available, and subsequently distribute this data to intelligent systems. During this presentation Andrew will discuss some of the challenges the network operating model has faced in the past and how he believes OpenDaylight can bring about changes in the way we think about managing networks. In the talk Andrew will present some additions to MD-SAL, through which OpenDaylight can be used to acquire data from devices and distribute it to multiple systems

2. Using OpenDaylight for
Notification Driven Workflows
Andrew McLachlan – Principal Engineer
DEVNET-1164

3. • Why Notifications via Open Daylight?
• Lithium - Event Topic Broker
• Now what?
Agenda – It’s Thursday Afternoon
...........................................so I have just 7 slides 

4. Why Notifications in Open
Daylight?

5. Generalised Service Assurance / EMS Architecture Today
• Tight coupling of data
aggregation/store/analysis – realised
in product pipelines
• Products attempt to cover one or
more pipelines
• Filtering on aggregation to reduce
data volume
• Analysis functions largely based on
programmatic rules, derived topology
models and static thresholds
Polling /
Scripting
Logging
Traps / Event
threshhold
Data sources
Events
Data store
Perf
Analysis
Fault
Analysis
Data analysis
Stats
Log
Index/Searc
h
Logs
Polling
Event
aggregation
Data aggregation
Log
Aggregation
Dashboard &
Reporting
Dashboard &
Reporting
Outputs
Dashboard &
Reporting
• Characteristics:
• Inflexible – difficult to introduce
new analysis functions –
dependent on existing product
pipelines
• High cost developing /
maintaining analysis functions
• Cost / value ratio is unclear
• Ineffective analysis functions
• Inextensible – little or no
exchange of data between
pipelines (silo’d)
• Limited ability to mine OSS
dataset
• Very hard to implement reactive
OSS capabilities.

6. Subscribing to Big Data – Telemetry approach
• Big Data approach for OSS
• Move to a Publish and Subscribe principal
• Driven via Policy – Increased control of data,
without further cumbersome configuration
• Silo Limitation – Allow digestion of any data to
any App (policy controlled)
• Scale up – ‘1 to many’ approach
• Extensible - add new OSS apps quickly and
seamlessly, without network config, using
pub/sub approach
Data sources
Controller /
Message Bus Data
StoreAcquire method
Example
Outputs
Short term
data store
Polling /
receiving
Legacy
SNMP
Syslog,
Polling,
Screen
Scraping
Billing
(usage)
OSS / BSS
Business
Analytics
And so on
Long term
data store
Example Data
analysis
applications
Perf Analysis
(Infra)
Provisioning
Resource
management
Fault
Analysis
Ticketing
Telemetry
+
Over X
NETCONF/T
hrift/PB
Inventory
Manager
e.g. batch
processing
e.g. real-time
processing
e.g. real-
time feed
Platform
Security and
Threat Analysis

7. Lithium - Event Topic Broker

8. Notification support for Open Daylight –Legacy / Hybrid
Controller
Model-Driven SAL (MD-SAL)
Event Topic Broker
Netconf Client
REST APIs
Network Device
Netconf Server
Data
Store
Device
Agent
Syslog / SNMP CLI plugins• Legacy (in the works)
• Controller performs data collection using polling
agents, syslog receivers, cli scraping etc
• Messages can be transformed via YANG models
or just tunnelled over the message bus to User
Agents (connector).
• Initial Plugin Support – NETCONF
(available Lithium)
• Transportation of messages over NETCONF
notifications. (syslog / snmp traps, polling etc)
• Received by NC Client, distributed via “Event
Topic Broker”
• User Agent Framework provides connectors to
any platform / application, e.g xmpp, tcp socket
etc
Network Device
Syslog / SNMPd/ CLI
Billing
(usage)
OSS / BSS
Business
Analytics
Perf Analysis
(Infra)
Provisioning
Resource
management
Fault
Analysis
Ticketing
Inventory
Manager
Security and
Threat AnalysisUser
Agents

9.  Creating a Topic
 POST http://localhost:8181/restconf/operations/event-aggregator:create-topic HEADERS Content-Type
application/json { "event-aggregator:input": { "notification-pattern": "pattern.of.notification.*", "node-id-
pattern":"router-17*" } } The request returns a topic-id unique to that particular topic., for example:
 { "output": { "topic-id": "9f4e18cd-06f0-4ad6-9d16-ad9a34eb4031" } } >>> unique topic-id
 Destroying a Topic
 POST http://localhost:8181/restconf/operations/event-aggregator:destroy-topic HEADERS Content-
Type application/json <destroy-topic> <topic-id>9f4e18cd-06f0-4ad6-9d16-ad9a34eb4031</topic-id>
</destroy-topic>
Topic Management via REST (Create / Destroy a Topic)

10.  Subscribing to the Topic
 POST: http://localhost:8181/restconf/operations/uagent-topic-read:read-topic HEADERS: Content-Type
application/json BODY: { "input": { "uagent-topic-read:topic-id": "c61d441c-ac01-4f23-983f-
cc53cf0d0cd7" } }
Output Topic to Connector / Application

11. Now what?

12. Notification Based Workflows. (Kinda the wrong title)
Dataset Driven Services
• Acquire data, lots of data, lots of different data.
Reachable – i.e topology
Historical – telemetry
Influential – internal / external variables (whatever you like)
Compute
reachable
• Ask Questions
f (x) type of condition
As a … I want to … so that…
• Evaluate Answers
move to provisioning
ask another question
drop

13. Stamping Config
• ODL is a modeled approach, so we have abstraction.
• An acceptable ‘Answer’ should contain the path / topology, resources
• At which point we move to programming elements.

14. Thank you