My talk on DIDM at OpenDaylight Summit 2015.
To watch the slides with animation, download the PPT from here: https://www.dropbox.com/s/hyo708cpjybmgrh/DIDM-ODL-SUMMIT-15.pptx?dl=0
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 –determine the type of device
2) Device Driver – provide device specific functionality
3) Synchronization – collecting and pushing data to/from a device
4) Define Data Models for Common Features – define data models for
performing common function such as VLAN configuration
5) 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
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
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
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