device driver framework project

17
www.opendaylight.org Device Driver Framework Project October 2014

Upload: vernados-karan

Post on 01-Jan-2016

25 views

Category:

Documents


0 download

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 Presentation

TRANSCRIPT

Page 1: Device Driver Framework Project

www.opendaylight.org

Device Driver Framework Project

October 2014

Page 2: Device Driver Framework Project

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

Page 3: Device Driver Framework Project

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?

Page 4: Device Driver Framework Project

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

Page 5: Device Driver Framework Project

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

Page 6: Device Driver Framework Project

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

Page 7: Device Driver Framework Project

www.opendaylight.org7

Component Diagram

Application

Device Manager

Device Service

Device Supplier Service Key

Manager

Key Service

Driver

DBDB

Page 8: Device Driver Framework Project

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

Page 9: Device Driver Framework Project

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

Page 10: Device Driver Framework Project

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

Page 11: Device Driver Framework Project

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

Page 12: Device Driver Framework Project

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

Page 13: Device Driver Framework Project

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

Page 14: Device Driver Framework Project

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

Page 15: Device Driver Framework Project

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

Page 16: Device Driver Framework Project

16

Q & A

Page 17: Device Driver Framework Project

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