devnet-1164using opendaylight for notification driven workflows

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


Why Notifications in Open Daylight?

4


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


Outputs


• 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.


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


Lithium - Event Topic Broker

7


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


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)


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


Now what?

11


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


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.

devnet-1164using opendaylight for notification driven workflows

Technology

exchange of data

data collection

data volume analysis

polling agents

lithium event topic

legacy snmp syslog

oss dataset

netconf notifications