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 ¨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
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