Device Identification & Driver Management (DIDM)

Device Identification and Driver Management (DIDM)Anandhi Manikantan, Hewlett-Packard

Gunjan Patel, Ciena Corporation

#ODSummit

Motivation

• Problems: • Today applications need to know the device’s capabilities to create flow mods that best utilize the

capabilities of the device• Controller doesn’t provide a common/consistent device specific way of handling CRUD operations for

functions such as VLAN configuration

• Motivation:• Need to provide Device specific functionality• Extensible -Allow new device specific functionality to be dynamically added, and allow dynamic support

for new device types• Standard/consistent way of implementing device specific functionality

#ODSummit

Scope

1) Identification –determine the type of device2) Device Driver – provide device specific functionality3) Synchronization – collecting and pushing data to/from a device4) Define Data Models for Common Features – define data models for

performing common function such as VLAN configuration5) Define RPCs for Common Features – define APIs (RPCs) for common

features such as Flow Mod adjustment 6) Discovery - discover a non-OpenFlow device (manual discovery)

#ODSummit

Design Considerations

Invoking DriversStandard MD-SAL mechanismsRPCs or invoked via a data change notification

Identification Framework component that orchestrates the Identification process.

Drivers provide Identification component with information to identify devices via MD-SAL mechanisms

Synchronization, Driver RegistrationUse standard MD-SAL mechanisms, event driven via notifications

(Decentralized)

#ODSummit

Dependencies

Credential Manager – work with AAA team SNMP Plugin

#ODSummit

MD-SAL enhancement Request

Enhancement requests that are yet to be implemented:Ability to control how much processing is given to a pluginFiner filter of data change notifications:

Eg, notify only if augmentation equal a specified value

#ODSummit

Component Diagram Identification Manager

#ODSummit

Identity

MD-SAL

Device-Types

3800

OF-info: HP, 3800sysOid: 1.2.3.4.5.6.7.8

5400

Sync

Device Driver

Config

Identification ManagerListen for

created nodes in Ops

Notified when data in Device-Types tree changes. Read new device type info

1

2

Driver (plugin)

Write identification info to Device-Types tree in Config data store OF-info: HP, 5400sysOid: 8.7.6.5.4.3.2.1

Component Diagram Identification Manager

#ODSummit

Credential Manager

Identity

MD-SAL

Nodes

Node

38005400

RS Driver

IID 3800

VLAN Driver 3800

IID 5400

VLAN Driver 5400

Routed RPCS

Create inventory node in Config and Operational data store

SNMP library

Sync

Device Driver

Config

Nodes

Node

38005400

Operational

DiscoveryOpenflowplugin

Identification ManagerListen for

created nodes in Ops

Notified when new node created

Augment with Device Type

3

1

4

Drivers Registered Drivers Registered

2

Driver (plugin)

Notified when Device Type

Augmentation applied

5

Apply augmentation with data collected

6

Register routed RPCs or for data change notifications

7

DIDM Manual Discovery

• Non-OpenFlow Discovery• Lifecycle management• Device Identification• Future work: integration with Credential Manager from AAA project • Device synchronization • Communications down• Communications up • Managed/Unmanaged state

#ODSummit

Discovery Request States

#ODSummit

Ident-Failed

Sync-Failed

Identifying…

Identified

Synchronizing…

Synchronized

Discovered!

Comms-down

Comms-up

State

Device States

#ODSummit

Discovered/ Managed

Deleted

Unmanaged

Unmanaged/ Comm down

Comms-down

Comms-up

Synchronizing

Device State

Discovery flow (1/2) [animation]

#ODSummit

Client

PUT inv:node {IP}

Oper

CHANGE Inv:node{ip}

PUBLISH unidentified device

Config NE Plugin

PUT Inv:node {ip, type}

Device

Connect

ok

Protocol Plugin (SNMP)

Connect

ok

MD-SAL Identification Mgr

Determine type

[Type Identified]

[Type Unidentified]

Discovery flow (2/2) [animation]

#ODSummit

Client Oper

RECEIVE Unidentified device

Config

PUT Inv:node {ip, type}

Device

Connect

ok

Protocol Plugin (TL1/CORBA)

Connect

ok

MD-SAL NE Plugin (Ciena 6500)

RECEIVE Unidentified device

NE Plugin (Ciena 5430)

Connect

failConnect

fail

Synchronization [animation]

#ODSummit

Client

PUT inv:node {‘syncing’}

Oper

Data change {‘sync’}

MERGE Inv:node <<data>>, {state:’synchronized’}

Config NE Plugin

PUT inv:node {state: ‘synching’}

Device

Get data

<data>

Protocol Plugin

Get data

<data>

#ODSummit

Lithium Deliverables Beryllium Goals Common model augmentations for device

type and device state

• Flow Mod driver

Device Drivers

Data models and APIs for common “features” such as VLAN configuration, Flow Mod adjustment, etc.

Identification components • VLAN driver • Add VLAN • Delete VLAN • Add port • Remove port

Documentation and sample driver • Non-OpenFlow discovery (Manual discovery)

Abstract/helper classes • Didm-feature-all (to install all the features)

• Tutorial on how to write a driver/use DIDM framework

Wiki and Trello• DIDM Wiki

• https://wiki.opendaylight.org/view/DIDM:Main• Meeting and IRC Slack info• Team members• Project proposal• Link to Trello board• Lithium Release plan

• Trello Board• https://trello.com/b/eUMAIoda/open-daylight-didm

#ODSummit

Thank you!

#ODSummit