Presentation is loading. Please wait.

Presentation is loading. Please wait.

Www.opendaylight.org Device Driver Framework Discussion September 2014.

Similar presentations


Presentation on theme: "Www.opendaylight.org Device Driver Framework Discussion September 2014."— Presentation transcript:

1 Device Driver Framework Discussion September 2014

2 Steve Dean Development Engineer Hewlett-Packard Working on HP’s SDN Controller for the past 2 years Contact info: Introduce Myself 2

3 What is a Device Driver Framework Use-cases to illustrate the concept High level description of HP’s design Discussion, Q&A Agenda 3

4 A framework that provides a standard and consistent way to implement device specific functionality Device Specific Functionality Often referred to as “Drivers”, or “Facets” Code that performs some function and 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? 4

5  Validate and Adjust FlowMods  Validate and adjust FlowMods to be sent to a device based on knowledge of the type of device  FlowMods adjustments can be made 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 5

6  Identification (Discovery)  Determines the type of each 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 Type Repository  Maintains identity information about the types of devices recognized by the framework  Maintains the Drivers that can use be with specific Device Types  Device Management  Maintain (persist) the discovered device information (eg, device type, port status)  API to allow applications to obtain device information  Security Credential Repository  Maintain and manage security credentials to allow interaction with devices  API to allow applications to obtain security information and populate the repository  Device Drivers  Device specific software components that make use of the information about the type of device Major Components 6

7 Component Diagram 7 Application Device Manager Device Service Device Supplier Service Device Supplier OF Device Discovery Device Supplier Device Driver Manager Device Driver Service Device Type XML Key Manager Key Service Driver 9 DB

8 Component Diagram 8 Application Device Manager Device Service Device Supplier Service Key Manager Key Service Driver DB

9 Device Type Repository 9 9 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 Handler Driver -Interface Handler Driver -Notification Handler Driver -Device Type = Extends HP Switch -Flags = isChassis -Device Type = J9642A, Extends 5400, Product=Switch 5406zl, OID= , FlowMod Driver -Device Type = J9643A, Extends 5400, Product=Switch 5412zl, OID= , FlowMod Driver

10 Evolution Process 10 BaseSwitch.xml HP.xml 5400.xml -Device Type = Default Switch -Device Type = HP Switch -Extends Default Switch -Vendor=HP -DeviceIdentityHandler Driver -Device Type = Extends HP Switch -Flags = isChassis -DeviceIdentityHandler Driver -Device Type = J9642A, Extends 5400, Product=Switch 5406zl, OID= , Facet=OpenFlow -Device Type = J9643A, Extends 5400, Product=Switch 5412zl, OID= , Facet=OpenFlow Example: 5406z1 that allows V1 modules, OF info is mfr=HP, hw=5400 v1.2.3, sw=KA_1_2_3 Step 1: Use OF information (mfr=HP, hw=5400 v1.2.3, sw=KA_1_2_3) to determine the device type is HP Switch Step 2: Use DeviceIdentityHandler Driver to fetch snmp sysOid from device Step 3: Use sysOid to determine device is 5406zl Step 4: We learn from the xml data that the device is a chassis Step 5: Use DeviceIdentityHandler Driver to fetch AllowV1 mib object Step 6: AllowV1 mib object tells us the device allows V1 modules

11  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 11

12 12  Is this something you think is useful?  Is there work in other areas to accomplish the same thing that I’m not aware of?

13 13

14  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  Identification (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 ODL Architecture and Design Decisions 14

15  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 ODL Architecture and Design Decisions continued 15

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

17 ODL Component Diagram – Option 2 17 MD-SAL Identification (discovery) GUI/REST/ Notification Hide MD-SAL from Applications Register RPCs Nodes Node Driver 3800 Driver Device Manager Application Credential Manager Device Driver Manager IDDriver 5400VLAN Driver VLAN Driver 3800 Routed RPCS Augment Data Store

18 ODL Component Diagram – Option 3 18 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 Application Credential Manager Device Driver Manager IDDriver 5400VLAN Driver VLAN Driver 3800 Routed RPCS Augment Data Store Device Manager Augment Data Store Register RPCs

19 Facet: Software that is used to perform a function that does not require interaction with the device, but required knowledge of the device. Eg, FlowMod Facet (validate and adjust FlowMods based on hardware capabilities and limitations). HandlerFacet: Software that is used to perform a function that requires interaction with a device. Eg, interact with a device to discover how it’s configured. Eg, VxLAN Tunnel Endpoint configuration. Facets and HandlerFacets are associated with a specific type of device and their implementation is specified in the Device Type XML file. Terminology 19

20 HP.xml 20 HP

21 xml 21 ProCurve 5400zl J9642A Switch 5406zl J9643A Switch 5412zl


Download ppt "Www.opendaylight.org Device Driver Framework Discussion September 2014."

Similar presentations


Ads by Google