device driver framework project
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
www.opendaylight.org
Device Driver Framework Project
October 2014
www.opendaylight.org2
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
www.opendaylight.org3
• 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?
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
www.opendaylight.org5
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
www.opendaylight.org6
Component Diagram
Application
Device Manager
Device Service
Device Supplier Service
Device Supplier Device Supplier OF Device Identification
Device Supplier
Device Driver Manager
Device Driver Service
Device Type XML
1
27
8
Key Manager
Key Service
3
4
5
6
Driver
9
DB
DB
www.opendaylight.org7
Component Diagram
Application
Device Manager
Device Service
Device Supplier Service Key
Manager
Key Service
Driver
DBDB
www.opendaylight.org8
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)
Application Usage
www.opendaylight.org9
ODL Component Diagram – Option 1
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.
RegisterRPCs
Nodes
Node
Driver3800
Driver 5400
38005400
Application
Credential Manager
Device Driver
Manager
ID Driver
5400 VLAN Driver 5400
3800 VLAN Driver 3800
Routed RPCS
Augment Data Store
www.opendaylight.org10
ODL Component Diagram – Option 2
MD-SAL
Identification (discovery)
GUI/REST/Notification
Hide MD-SAL from Applications
RegisterRPCs
Nodes
Node
Driver3800
Driver 5400
38005400
Device Manager
Application
Credential Manager
Device Driver
Manager
ID Driver
5400 VLAN Driver 5400
3800 VLAN Driver 3800
Routed RPCS
Augment Data Store
- Apps do not need to be MD-SAL aware- Preserve existing APIs
www.opendaylight.org11
ODL Component Diagram – Option 3
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.
RegisterRPCs
Nodes
Node
Driver3800
Driver 5400
3800 5400
Application
Credential Manager
Device Driver
Manager
ID Driver
5400 VLAN Driver 5400
3800 VLAN Driver 3800
Routed RPCS
Augment Data Store
Device Manager
Augment Data Store Register
RPCs
Store securityKeys in MD-SALData store
www.opendaylight.org12
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
www.opendaylight.org13
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
www.opendaylight.org14
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
www.opendaylight.org15
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
16
Q & A
www.opendaylight.org17
Device Type Repository
17
BaseSwitch.xml
HP.xml Cisco.xml
3800.xml 5400.xml 5900.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