1 / 17

Device Driver Framework Project

Device Driver Framework Project. October 2014. Problem. 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

vernados-karan
Télécharger la présentation

Device Driver Framework Project

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 Project October 2014

  2. Problem • 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

  3. 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” • 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

  4. 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 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

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

  6. 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 Identification Driver 5 2 7 Key Service DB 6 Key Manager

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

  8. 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)

  9. 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 routed RPC service. Augment Data Store Register RPCs GUI/REST/ Notification Credential Manager Identification (Discovery) Device Driver Manager

  10. 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 - Apps do not need to be MD-SAL aware - Preserve existing APIs Register RPCs GUI/REST/ Notification Credential Manager Identification (discovery) Device Driver Manager

  11. 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. Store security Keys in MD-SAL Data store Augment Data Store Register RPCs Credential Manager GUI/REST/ Notification Identification (Discovery) Device Driver Manager

  12. Status • 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

  13. Concerns • 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

  14. 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 • 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. 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. Q & A

  17. Device Type Repository BaseSwitch.xml • Device Type Name = Default Switch • Device Type = HP Switch • Extends Default Switch • Vendor=HP • Device Identity Driver • Interface Driver • Notification 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 17

More Related