1. www.opendaylight.org Device Driver Framework Project October 2014

2. www.opendaylight.org  How do we deal with devices with different capabilities and limitations?  Even though Openflow is a standard, devices have different Openflow capabilities  Need a way to implement Device Specific Functionality  Solution: Device Driver Framework Problem 2

3. www.opendaylight.org A framework that provides a standard and consistent way to implement device specific functionality Device Specific Functionality Often referred to as “Drivers” Code that performs some function, and that code is knowledgeable of the capabilities and limitation of a Device Framework: Extensible to allow dynamic support for new device types Extensible to allow new device specific functionality to be dynamically added What is a Device Driver Framework? 3

4. www.opendaylight.org  Validate and Adjust FlowMods  Validate and adjust FlowMods to be sent to a device based on knowledge of the type of device  FlowMods adjusted to take advantages of capabilities of the device  VLAN Configuration  Perform VLAN CRUD operations using communication protocols such as SNMP, NetConf, CLI  VxLAN Configuration  Perform VxLAN CRUD operations using communication protocols such as SNMP, NetConf  Any device specific functionality Use-Cases 4

5. www.opendaylight.org  Device Type Repository  Maintains identity information about the types of physical devices recognized by the framework  Identification  Determines the type of each physical device using information discovered through OpenFlow handshakes, as well as direct interaction with the device  Communicate with device to discovery configuration information that may affect the devices capabilities and limitations  Device Management  Maintain (persist??) the discovered device information (eg, device type, port status)  API to allow applications to obtain device information  Security Repository  Maintain and manage security credentials to allow interaction with devices  API to allow applications to obtain security information  Device Drivers  Device specific software components that makes use of the information about the type of device Major Components 5

6. www.opendaylight.org Component Diagram 6 Application Device Manager Device Service Device Supplier Service Device Supplier OF Device Identification Device Supplier Device Driver Manager Device Driver Service Device Type XML 1 2 7 8 Key Manager Key Service 3 4 5 6 Driver 9 DB

7. www.opendaylight.org Component Diagram 7 Application Device Manager Device Service Device Supplier Service Key Manager Key Service Driver DB

8. www.opendaylight.org  Device Service Interface  Get Device object  Eg, Set getDevice(DeviceFilter filter)  Get Interface information  Eg, List getInterfaces(Device device)  Device and Interface notifications  Eg, addListener(DeviceListener listener)  Device Interface  Eg, Boolean isOnline()  Eg, Set getDriverrClassNames()  Eg, Boolean isSupprted(Class driverClass)  Eg, T getDriver(DriverClass driverClass)  Application Usage 8

9. www.opendaylight.org ODL Component Diagram – Option 1 9 MD-SAL Identification (Discovery) GUI/REST/ Notification - Identification (Discovery) determines device type and augments data store and registers Routed RPC. - Applications use MD- SAL routed RPC service. Register RPCs Nodes Node Driver 3800 Driver 5400 3800 5400 Application Credential Manager Device Driver Manager IDDriver 5400VLAN Driver 5400 3800VLAN Driver 3800 Routed RPCS Augment Data Store

10. www.opendaylight.org ODL Component Diagram – Option 2 10 MD-SAL Identification (discovery) GUI/REST/ Notification Hide MD-SAL from Applications Register RPCs Nodes Node Driver 3800 Driver 5400 3800 5400 Device Manager Application Credential Manager Device Driver Manager IDDriver 5400VLAN Driver 5400 3800VLAN Driver 3800 Routed RPCS Augment Data Store - Apps do not need to be MD-SAL aware - Preserve existing APIs

11. www.opendaylight.org ODL Component Diagram – Option 3 11 MD-SAL Identification (Discovery) GUI/REST/ Notification - Device Manger provides Application API and Identification API. - Device Manager is the only component that is MD-SAL aware. Register RPCs Nodes Node Driver 3800 Driver 5400 3800 5400 Application Credential Manager Device Driver Manager IDDriver 5400VLAN Driver 5400 3800VLAN Driver 3800 Routed RPCS Augment Data Store Device Manager Augment Data Store Register RPCs Store security Keys in MD-SAL Data store

12. www.opendaylight.org  Project Proposal posted to ODL wiki 2 weeks ago  Learning ODL and MD-SAL  Prototyping and porting some HP code to ODL  Openflow identification  Key Manager  Device Driver Manager  SNMP library  Augment inventory node with device type  Register drivers as routed RPCs  Simple test application Status 12

13. www.opendaylight.org  MD-SAL data store encryption  Nice to have MD-SAL encrypt data  Currently we encrypt before storing in MD-SAL data store  Prevents use of RestConf to read/write Key data  Config Subsystem  Difficult to learn, takes too much time to learn  Better documentation will help  Routed RPCs (yang)  How to pass a flowmod type as an input parameter  How to return a set of flowmods as an output parameter  How to specific complex types and Sets in yang model Concerns 13

14. www.opendaylight.org  Device Type Repository  How to represent device type information (eg, xml)  How and where to store in-memory device type information (MD-SAL data store)  Define how new device type information can be dynamically added to the system  Discovery  Define phase 1 discovery components (OpenFlow, Manual)  Define “evolution” process  Device Management  Do we want to maintain device information  Define how to store in-memory device information and what should be stored (MD-SAL data store)  Define API Architecture and Design Decisions 14

15. www.opendaylight.org  Security Repository  Define how to store security information (MD-SAL data store)  Define how to populate security repository  Define API  Device Drivers  Define how to implement device drivers  Can device drivers be implemented as “routed” RPCs and associated with a device inventory node in the MD-SAL data store?  Define how new device drivers can be dynamically added to the system Architecture and Design Decisions continued 15

16. 16

17. www.opendaylight.org Device Type Repository 17 17 BaseSwitch.xml HP.xml Cisco.xml 3800.xml5400.xml5900.xml -Device Type Name = Default Switch -Device Type = HP Switch -Extends Default Switch -Vendor=HP -Device Identity Driver -Interface Driver -Notification Driver -Device Type = 5400 -Extends HP Switch -Flags = isChassis -Device Type = J9642A, Extends 5400, Product=Switch 5406zl, OID=1.3.6.1.4.1.11.2.3.7.11.50, FlowMod Driver -Device Type = J9643A, Extends 5400, Product=Switch 5412zl, OID=1.3.6.1.4.1.11.2.3.7.11.51, FlowMod Driver