1 / 21

Device Driver Framework Discussion

Device Driver Framework Discussion. September 2014. Introduce Myself. Steve Dean Development Engineer Hewlett-Packard Working on HP’s SDN Controller for the past 2 years Contact info: sdean@hp.com , 916-785-3429. Agenda. What is a Device Driver Framework

garrison-neal
Télécharger la présentation

Device Driver Framework Discussion

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Device Driver Framework Discussion September 2014

  2. Introduce Myself • Steve Dean • Development Engineer • Hewlett-Packard • Working on HP’s SDN Controller for the past 2 years • Contact info: sdean@hp.com, 916-785-3429

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

  4. What is a Device Driver Framework? • 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

  5. Use-Cases • 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

  6. Major Components • 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

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

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

  9. Device Type Repository BaseSwitch.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 HP.xml Cisco.xml 3800.xml 5400.xml 5900.xml • 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 9

  10. Evolution Process • 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 snmpsysOid from device • Step 3: Use sysOidto determine device is 5406zl • Step 4: We learn from the xml data that the device is a chassis • Step 5: Use DeviceIdentityHandler Driverto fetch AllowV1 mib object • Step 6: AllowV1 mib object tells us the device allows V1 modules • Device Type = Default Switch BaseSwitch.xml • Device Type = HP Switch • Extends Default Switch • Vendor=HP • DeviceIdentityHandlerDriver HP.xml 5400.xml • Device Type = 5400 • Extends HP Switch • Flags = isChassis • DeviceIdentityHandler Driver • Device Type = J9642A, Extends 5400, Product=Switch 5406zl, OID=1.3.6.1.4.1.11.2.3.7.11.50, Facet=OpenFlow • Device Type = J9643A, Extends 5400, Product=Switch 5412zl, OID=1.3.6.1.4.1.11.2.3.7.11.51, Facet=OpenFlow

  11. Application Usage • Device Service Interface • Get Device object • Eg, Set<Device> getDevice(DeviceFilter filter) • Get Interface information • Eg, List<Interface> getInterfaces(Device device) • Device and Interface notifications • Eg, addListener(DeviceListener listener) • Device Interface • Eg, Boolean isOnline() • Eg, Set<String> getDriverrClassNames() • Eg, Boolean isSupprted(Class<? extends Driver> driverClass) • Eg, <T extends Driver> T getDriver(DriverClass<T> driverClass)

  12. Q & A • 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. Backup Slides

  14. ODL Architecture and Design Decisions • 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

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

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

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

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

  19. Terminology • 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.

  20. HP.xml <deviceDriver description="HP device driver for switches"> <type name="HP Switch" extends="Default Switch"> <facet name="com.hp.device.DeviceIdentityHandler" class="com.hp.sdn.dvc.facet.impl.HpDeviceIdentityHandler"/> <facet name="com.hp.sdn.dvc.facet.InterfaceHandler" class="com.hp.sdn.dvc.facet.impl.SnmpInterfaceHandler"/> <facet name="com.hp.sdn.dvc.facet.NotificationHandler" class="com.hp.sdn.dvc.facet.impl.SnmpNotificationHandler"/> <vendor>HP</vendor> </type> </deviceDriver>

  21. 5400.xml <deviceDriver description="HP 5400 Switch"> <type name="5400" extends="HP Switch"> <facet name="com.hp.sdn.dvc.facet.FlowModFacet" class="com.hp.sdn.dvc.facet.impl.FlowModFacetFactory"/> <family>ProCurve 5400zl</family> <product>5400</product> <flag name="isChassis" /> </type> <type name="J9642A" extends="5400" description="5406zl"> <oid>.1.3.6.1.4.1.11.2.3.7.11.50</oid> <model>J9642A</model> <product>Switch 5406zl</product> </type> <type name="J9643A" extends="5400" description="5412zl"> <oid>.1.3.6.1.4.1.11.2.3.7.11.51</oid> <model>J9643A</model> <product>Switch 5412zl</product> </type> </deviceDriver>

More Related