Device Driver
Framework Project
October 2014
www.opendaylight.org
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
www.opendaylight.org
2
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
www.opendaylight.org
3
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
www.opendaylight.org
4
Major Components

Device Type Repository


Identification




Maintain (persist??) the discovered device information (eg, device type, port status)
API to allow applications to obtain device information
Security Repository



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


Maintains identity information about the types of physical devices recognized by the
framework
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
www.opendaylight.org
5
Component Diagram
Application
9
Device Driver Service
Device Driver Manager
Device Service
DB
Device Manager
Device Supplier Service
1
3
8
4
Device Supplier
2
Device
Type
XML
Device Supplier
Driver
Supplier
OFDevice
Device Identification
7
6
5
Key Service
Key Manager
DB
www.opendaylight.org
6
Component Diagram
Application
Driver
Device Service
DB
Device Manager
Device Supplier Service
Key Service
Key Manager
www.opendaylight.org
DB
7
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,
Eg,
Eg,
Eg,
Boolean isOnline()
Set<String> getDriverrClassNames()
Boolean isSupprted(Class<? extends Driver> driverClass)
<T extends Driver> T getDriver(DriverClass<T> driverClass)

www.opendaylight.org
8
ODL Component Diagram – Option 1
Application
Driver
3800
Nodes
MD-SAL
Routed RPCS
Node
3800
Augment
Data Store
GUI/REST/
Notification
Identification
(Discovery)
Driver
5400
5400
ID
Driver
5400
VLAN Driver 5400
3800
VLAN Driver 3800
Register
RPCs
Credential
Manager
Device
Driver
Manager
- Identification (Discovery)
determines device type
and augments data store
and registers Routed
RPC.
- Applications use MDSAL routed RPC service.
www.opendaylight.org
9
ODL Component Diagram – Option 2
Hide MD-SAL from Applications
Application
Device Manager
Driver
3800
Nodes
MD-SAL
Routed RPCS
Node
3800
Augment
Data Store
Driver
5400
5400
ID
Driver
5400
VLAN Driver 5400
3800
VLAN Driver 3800
- Apps do not need to be
MD-SAL aware
Register
RPCs
- Preserve existing APIs
GUI/REST/
Notification
Identification
(discovery)
Credential
Manager
Device
Driver
Manager
www.opendaylight.org
10
ODL Component Diagram – Option 3
Application
Driver
3800
Device
Manager
Augment
Data Store
MD-SAL
Nodes
Routed RPCS
Node
3800
Driver
5400
5400
ID
Driver
5400
VLAN Driver 5400
3800
VLAN Driver 3800
Register
RPCs
Augment
Data Store
GUI/REST/
Notification
Store security
Keys in MD-SAL
Data store
Register
RPCs
Identification
(Discovery)
Credential
Manager
Device
Driver
Manager
- Device Manger provides
Application API and
Identification API.
- Device Manager is the
only component that is
MD-SAL aware.
www.opendaylight.org
11
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
www.opendaylight.org
12
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
www.opendaylight.org
13
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
www.opendaylight.org
14
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
www.opendaylight.org
15
16
Device Type Repository
BaseSwitch.xml
HP.xml
3800.xml
5400.xml
-
-
Device Type = HP Switch
Extends Default Switch
Vendor=HP
Device Identity Driver
Interface Driver
Notification Driver
- Device Type Name = Default Switch
Cisco.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
1
7
www.opendaylight.org
17