Device Identification & Driver Management TSC Update January 8, 2015

History 2  Posted the Device Driver Framework (DDF) Project on 10/21/2014  DDF design was an attempt to highly leverage HP’s design  After learning more about ODL/MD-SAL and working with Discovery team we have changed the focus to better work with MD-SAL  Changed the name to Device Identification and Driver Management (DIDM)  Defined DIDM as offset-2 project

Motivation 3  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

Scope 4  We are addressing the following: 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 flowmod adjustment 6)Discovery - discover that a new device exists (manual discovery)

Deliverables 5  Common model augmentations for device type and device state  Data models and APIs for common “features” such as vlan configuration, flow mod adjustment, etc.  Device Drivers  Identification components  Documentation and sample driver  Abstract/helper classes

Design Considerations 6  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)

Dependencies 7  Credential Manager – work with AAA team  SNMP Plugin

MD-SAL Enhancement Requests 8  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

Ownership 9  Credential Manager should be owned by AAA project team  Common data models for performing functions such as vlan config should be owned by Controller project (ie, put all data models in a central location)  Are data models being moded to Openflowplugin project?

Immediate Next Steps 10  Update project Proposal with committers  Create a Main wiki page  Create a High Level Lithium Release Plan  Elect a Project Lead

Project Details 11  Project Lead – Steve Dean  Project Contact – Steve Dean  Test Contact – Steve Dean  Draft Lithium Release Plan – Available for review 

Backup 12

Component Diagram Identification Manager 13 Identity MD-SAL Device-Types 3800 OF-info: HP, 3800 sysOid: 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) Write identification info to Device- Types tree in Config data store OF-info: HP, 5400 sysOid:

Component Diagram Identification Manager 14 Credential Manager Identity MD-SAL Nodes Node RSDriver IID 3800 VLAN Driver 5400 IID 5400 VLAN Driver 3800 Routed RPCS Create inventory node in Config and Operational data store SNMP library Sync Device Driver Config Nodes Node Operational Discovery Identification Manager Listen for created nodes in Ops Notified when new node created Augment with Device Type 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