ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo
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 ¨Cdetermine the type of device
2) Device Driver ¨C provide device specific functionality
3) Synchronization ¨C collecting and pushing data to/from a device
4) Define Data Models for Common Features ¨C define data models for
performing common function such as VLAN configuration
5) Define RPCs for Common Features ¨C define APIs (RPCs) for common
features such as Flow Mod adjustment
6) Discovery - discover a non-OpenFlow device (manual discovery)
#ODSummit
Design Considerations
?Invoking Drivers
?Standard MD-SAL mechanisms
?RPCs 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 Registration
?Use standard MD-SAL mechanisms, event driven via notifications
(Decentralized)
#ODSummit
Dependencies
?Credential Manager ¨C 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 plugin
?Finer 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, 3800
sysOid: 1.2.3.4.5.6.7.8
5400
Sync
Device Driver
Config
Identification
Manager
Listen for
created nodes
in Ops
Notified when data in
Device-Types tree
changes. Read new
device type info
1
2
Driver (plugin)
OF-info: HP, 5400
sysOid: 8.7.6.5.4.3.2.1
Component Diagram
Identification Manager
#ODSummit
Credential
Manager
Identity
MD-SAL
Nodes
Node
3800
5400
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
3800
5400
Operational
Discovery
Openflowplugin
Identification
Manager
Listen for
created nodes
in Ops
Notified when
new node
created
Augment with
Device Type
3
1
4
Drivers Registered Drivers Registered
2
Driver (plugin)
5
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
fail
Connect
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

More Related Content

Device Identification & Driver Management (DIDM)

  • 1. Device Identification and Driver Management (DIDM) Anandhi Manikantan, Hewlett-Packard Gunjan Patel, Ciena Corporation #ODSummit
  • 2. 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
  • 3. Scope 1) Identification ¨Cdetermine the type of device 2) Device Driver ¨C provide device specific functionality 3) Synchronization ¨C collecting and pushing data to/from a device 4) Define Data Models for Common Features ¨C define data models for performing common function such as VLAN configuration 5) Define RPCs for Common Features ¨C define APIs (RPCs) for common features such as Flow Mod adjustment 6) Discovery - discover a non-OpenFlow device (manual discovery) #ODSummit
  • 4. Design Considerations ?Invoking Drivers ?Standard MD-SAL mechanisms ?RPCs 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 Registration ?Use standard MD-SAL mechanisms, event driven via notifications (Decentralized) #ODSummit
  • 5. Dependencies ?Credential Manager ¨C work with AAA team ?SNMP Plugin #ODSummit
  • 6. MD-SAL enhancement Request Enhancement requests that are yet to be implemented: ?Ability to control how much processing is given to a plugin ?Finer filter of data change notifications: ?Eg, notify only if augmentation equal a specified value #ODSummit
  • 7. Component Diagram Identification Manager #ODSummit Identity MD-SAL Device-Types 3800 OF-info: HP, 3800 sysOid: 1.2.3.4.5.6.7.8 5400 Sync Device Driver Config Identification Manager Listen for created nodes in Ops Notified when data in Device-Types tree changes. Read new device type info 1 2 Driver (plugin) OF-info: HP, 5400 sysOid: 8.7.6.5.4.3.2.1
  • 8. Component Diagram Identification Manager #ODSummit Credential Manager Identity MD-SAL Nodes Node 3800 5400 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 3800 5400 Operational Discovery Openflowplugin Identification Manager Listen for created nodes in Ops Notified when new node created Augment with Device Type 3 1 4 Drivers Registered Drivers Registered 2 Driver (plugin) 5 6 Register routed RPCs or for data change notifications 7
  • 9. 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
  • 12. 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]
  • 13. 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 fail Connect fail
  • 14. 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>
  • 15. #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
  • 16. 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

Editor's Notes