Date post: | 08-Aug-2015 |
Category: |
Technology |
Upload: | cisco-devnet |
View: | 166 times |
Download: | 2 times |
Using OpenDaylight for Notification Driven Workflows
Andrew McLachlan – Principal Engineer
DEVNET-1164
© 2015 Cisco and/or its affiliates. All rights reserved. Cisco PublicPresentation ID
• Why Notifications via Open Daylight?
• Lithium - Event Topic Broker
• Now what?
Agenda – It’s Thursday Afternoon...........................................so I have just 7 slides ☺
3
© 2015 Cisco and/or its affiliates. All rights reserved. Cisco PublicPresentation ID
Why Notifications in Open Daylight?
4
© 2015 Cisco and/or its affiliates. All rights reserved. Cisco PublicPresentation ID
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/SearchLogs
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.
© 2015 Cisco and/or its affiliates. All rights reserved. Cisco PublicPresentation ID
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
LegacySNMPSyslog,Polling,ScreenScraping
Billing (usage)
OSS / BSS
Business Analytics
And so on
Long term data store
Example Data analysisapplications
Perf Analysis (Infra)
Provisioning
Resource management
Fault Analysis
Ticketing
Telemetry +
Over XNETCONF/
Thrift/PB
Inventory Manager
e.g. batchprocessing
e.g. real-timeprocessing
e.g. real-time feed
Platform
Security and Threat Analysis
© 2015 Cisco and/or its affiliates. All rights reserved. Cisco PublicPresentation ID
Lithium - Event Topic Broker
7
© 2015 Cisco and/or its affiliates. All rights reserved. Cisco PublicPresentation ID
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
© 2015 Cisco and/or its affiliates. All rights reserved. Cisco PublicPresentation ID
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)
© 2015 Cisco and/or its affiliates. All rights reserved. Cisco PublicPresentation ID
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
© 2015 Cisco and/or its affiliates. All rights reserved. Cisco PublicPresentation ID
Notification Based Workflows. (Kinda the wrong title)Dataset Driven Services
12
• Acquire data, lots of data, lots of different data.Reachable – i.e topologyHistorical – telemetryInfluential – internal / external variables (whatever you like)
Compute
reachable
historicalinfluentia
l
• Ask Questionsf (x) type of conditionAs a … I want to … so that…
• Evaluate Answersmove to provisioningask another questiondrop
© 2015 Cisco and/or its affiliates. All rights reserved. Cisco PublicPresentation ID
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.