Www.opendaylight.org Device Driver Framework Project October 2014.

Slides:



Advertisements
Similar presentations
Top-Down Network Design Chapter Nine Developing Network Management Strategies Copyright 2010 Cisco Press & Priscilla Oppenheimer.
Advertisements

Proposal: Model-Driven SAL for the OpenDaylight Controller
IHE Profile Proposal: Dynamic Configuration Management October, 2013.
Web Service Ahmed Gamal Ahmed Nile University Bioinformatics Group
January 2014 Thomas D. Nadeau
Device Driver Framework Discussion
OpenDaylight: An Open Source SDN for Your OpenStack Cloud Stephan Baucke, Ericsson Kyle Mestery, Cisco Anees Shaikh, IBM Chris Wright,
Time Series Data Repository (TSDR)
OpenDaylight Architecture ONF Member Work Day February 12 th, 2015 Colin TSC Chair, OpenDaylight Principal Engineer, Brocade.
Extensible Networking Platform IWAN 2005 Extensible Network Configuration and Communication Framework Todd Sproull and John Lockwood
G O B E Y O N D C O N V E N T I O N WORF: Developing DB2 UDB based Web Services on a Websphere Application Server Kris Van Thillo, ABIS Training & Consulting.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Notes to the presenter. I would like to thank Jim Waldo, Jon Bostrom, and Dennis Govoni. They helped me put this presentation together for the field.
©2015 Extreme Networks, Inc. All rights reserved. Software Defined Networking (SDN) v2.0 Mikael Holmberg Senior Global Consulting Engineer
SWE Introduction to Software Engineering
Integration of Applications MIS3502: Application Integration and Evaluation Paul Weinberg Adapted from material by Arnold Kurtz, David.
NOV 20, 2014 Abi Varghese Tiju John Mahesh Govind
SNMP Plugin TSC Update December,
1 The Cryptographic Token Key Initialization Protocol (CT-KIP) Web Service Description KEYPROV WG IETF-68 Prague March 2007 Andrea Doherty.
OpenDaylight Architecture
The Design Discipline.
1 A Common API for Transparent Hybrid Multicast (draft-waehlisch-sam-common-api-04) Matthias Wählisch, Thomas C. Schmidt Stig Venaas {waehlisch,
Chapter 7: Architecture Design Omar Meqdadi SE 273 Lecture 7 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Ed Warnicke – Note: Read with animations
NOX an OpenFlow controller. Role of Controller in OpenFlow Environments Push forwarding logic to switches Give developers a high-level API to develop.
1 CMPT 275 High Level Design Phase Architecture. Janice Regan, Objectives of Design  The design phase takes the results of the requirements analysis.
1 Tools for Commercial Component Assembly Francis Bordeleau, Zeligsoft/Carleton University Mark Vigder, National Research Council Canada.
Persistence Store Project Proposal.
Draft-shafer-netconf-syslog-00.txt Phil Shafer July 2006 IETF 66, Montreal.
Lecture 15 Introduction to Web Services Web Service Applications.
Process Management Working Group Process Management “Meatball” Dallas November 28, 2001.
OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN. COURSE OUTLINE The world of the Information Systems Analyst Approaches to System Development The Analyst as.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
© Hitachi, Ltd All rights reserved. NETCONF Configuration I/F Advertisement by WSDL and XSD Hideki Okita, Tomoyuki Iijima, Yoshifumi Atarashi, Ray.
Approaching a Problem Where do we start? How do we proceed?
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
Web Services BOF This is a proposed new working group coming out of the Grid Computing Environments Research Group, as an outgrowth of their investigations.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
ASAP RDF SGP RDF 1.2 and 1.3 Transfer of Information
HP OpenFlow Plugin and Libraries June 30, 2014.
EbXML Messaging Upgrade of OAG TestBed: Some Requirements and Design Options Jacques Durand / Philippe DeSmedt ebXML IIC.
Device Identification & Driver Management TSC Update January 8, 2015.
PwC New Technologies New Risks. PricewaterhouseCoopers Technology and Security Evolution Mainframe Technology –Single host –Limited Trusted users Security.
Protocol for I2RS I2RS WG IETF #89 London, UK Dean Bogdanovic v0.1.
Project Database Handler The Project Database Handler is a brokering application that mediates interactions between the project database and the external.
Chapter 7: Architectural Design Chapter 11 in textbook 1.
Jini Architecture Introduction System Overview An Example.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
December 30, 2015 Richard Chien Marko Lai Jason Yuan
Controller spin-off proposals
Ryu Overview 2014/11/25 晁鍾義 Tony. What is Ryu ? Component and Ryu What is component ? Component and libraries in the Ryu and description Ryu Architecture.
+ Routing Concepts 1 st semester Objectives  Describe the primary functions and features of a router.  Explain how routers use information.
Created by Jan Medved I2RS Related/Relevant Yang Models Currently in Use March 2014 Robert Varga, Anton Tkacik, Jan Medved.
Slide 1 2/22/2016 Policy-Based Management With SNMP SNMPCONF Working Group - Interim Meeting May 2000 Jon Saperia.
Lecture VI: SOAP-based Web Service CS 4593 Cloud-Oriented Big Data and Software Engineering.
Azher Mughal / Beraldo Leal Programming OpenFlow Flows for Scientific Profit 1 Azher Mughal / Beraldo Leal SuperComputing 2015.
Copyright 2007, Information Builders. Slide 1 iWay Web Services and WebFOCUS Consumption Michael Florkowski Information Builders.
Clustering in OpenDaylight
Test and Performance Integration Group.
Author: Maros Marsalek (Honeycomb PTL)
I2rs Requirements for NETCONF IETF 93. Requirement Documents
Atrium Router Project Proposal Subhas Mondal, Manoj Nair, Subhash Singh.
System Architecture CS 560. Project Design The requirements describe the function of a system as seen by the client. The software team must design a system.
OpenDaylight Hydrogen Release Sept 2, 2013.
Junos Automation Stack
OpenDaylight Clustering – What’s new in Boron
IP/MPLS Backbone Transition to SDN: OpenDaylight Advisory Board
Honeycomb design and architecture
Factory default Setting draft-wu-netmod-factory-default-01
NMDA Q & A draft-dsdt-nmda-guidelines &
Presentation transcript:

Device Driver Framework Project October 2014

 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 2

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? 3

 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

 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 5

Component Diagram 6 Application Device Manager Device Service Device Supplier Service Device Supplier OF Device Identification Device Supplier Device Driver Manager Device Driver Service Device Type XML Key Manager Key Service Driver 9 DB

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

 Device Service Interface  Get Device object  Eg, Set getDevice(DeviceFilter filter)  Get Interface information  Eg, List getInterfaces(Device device)  Device and Interface notifications  Eg, addListener(DeviceListener listener)  Device Interface  Eg, Boolean isOnline()  Eg, Set getDriverrClassNames()  Eg, Boolean isSupprted(Class driverClass)  Eg, T getDriver(DriverClass driverClass)  Application Usage 8

ODL Component Diagram – Option 1 9 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. Register RPCs Nodes Node Driver 3800 Driver Application Credential Manager Device Driver Manager IDDriver 5400VLAN Driver VLAN Driver 3800 Routed RPCS Augment Data Store

ODL Component Diagram – Option 2 10 MD-SAL Identification (discovery) GUI/REST/ Notification Hide MD-SAL from Applications Register RPCs Nodes Node Driver 3800 Driver Device Manager Application Credential Manager Device Driver Manager IDDriver 5400VLAN Driver VLAN Driver 3800 Routed RPCS Augment Data Store - Apps do not need to be MD-SAL aware - Preserve existing APIs

ODL Component Diagram – Option 3 11 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. Register RPCs Nodes Node Driver 3800 Driver Application Credential Manager Device Driver Manager IDDriver 5400VLAN Driver VLAN Driver 3800 Routed RPCS Augment Data Store Device Manager Augment Data Store Register RPCs Store security Keys in MD-SAL Data store

 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 12

 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 13

 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 14

 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 15

16

Device Type Repository BaseSwitch.xml HP.xml Cisco.xml 3800.xml5400.xml5900.xml -Device Type Name = Default Switch -Device Type = HP Switch -Extends Default Switch -Vendor=HP -Device Identity Driver -Interface Driver -Notification Driver -Device Type = Extends HP Switch -Flags = isChassis -Device Type = J9642A, Extends 5400, Product=Switch 5406zl, OID= , FlowMod Driver -Device Type = J9643A, Extends 5400, Product=Switch 5412zl, OID= , FlowMod Driver