16
Southbound Plugins in OpenDaylight Srini Seetharaman Nov 2014

Using OVSDB and OpenFlow southbound plugins

Embed Size (px)

Citation preview

Page 1: Using OVSDB and OpenFlow southbound plugins

Southbound Plugins in OpenDaylight

Srini SeetharamanNov 2014

Page 2: Using OVSDB and OpenFlow southbound plugins

Life of a Packet for AD-SAL Apps

1. A packet arriving at Switch1 will be sent to the appropriate plugin managing the switch

2. The plugin will parse the packet, generate an event for SAL

3. SAL will dispatch the packet to the modules listening for DataPacket

4. Module handles packet and sends packet_out through IDataPacketService

5. SAL dispatches the packet to the modules listening for DataPacket

6. OpenFlow message sent to appropriate switch

2

Service Abstraction Layer (SAL)

OpenFlow

protocol plugin

OpenFlow

J

IPluginOutDataPacketService

IPluginInDataPacketService

ARP Handler

IListenDataPacket

OpenFlow

Switch1Switch2

Switch3

L2 Learning s/w

IListenDataPacket

IDataPacketService

(1)

(2)

(3)

(3)

(5)

(4)

(6)

Page 3: Using OVSDB and OpenFlow southbound plugins

• Statically defined shim layer that handles event going from application to switch, and vice-versa

• In above example, statically defined Java interfaces (i.e., the API) are used by each layer to specify events they handle‒ E.g., L2 learning switch implements IListenDataPacket API. So, when event

arrives arrives in SAL, it is appropriately converted (or normalized) and sent to the Application by calling the appropriate receivePacket() method

Intro to AD-SAL (API-driven SAL)

public interface IListenDataPacket {/*** Handler for receiving the packet.** @param inPkt Packet received* @return An indication if the packet should still be processed* or we should stop it.*/PacketResult receiveDataPacket(RawPacket inPkt);

}

Page 4: Using OVSDB and OpenFlow southbound plugins

• Data store and access models is core of the worflow

Intro to MD-SAL (Model-driven SAL)

4

Page 5: Using OVSDB and OpenFlow southbound plugins

AD-SAL OVSDB Plugin

Page 6: Using OVSDB and OpenFlow southbound plugins

OVSDB Plugin

Library

Database, Table, Column schema

OpenvSwitchSchema

Hardware_VTEPSchema

Northbound

OVSDBClientand connection

OVSDB Repository

Page 7: Using OVSDB and OpenFlow southbound plugins

Open_vSwitch Schema

Page 8: Using OVSDB and OpenFlow southbound plugins

Hardware_VTEP Schema

Page 9: Using OVSDB and OpenFlow southbound plugins

OVSDB Plugin Main Impl Classes

9

ConnectionService

Inventory Service

Listens to new connections • On new connection

updates inventory by calling processTableUpdates() and notifyNodeAdded() on inventory service

• Kicks off the OVSDB monitor

Keeps a local cache of all the information in the DB• On processTableUpdates

being called, it updates cache, and performs setOFController if it’s a Bridge table in the OVS schema

• Dispatches events to all other Inventory listeners

Configuration Service

Provider for OVSDB operations like insertRow, deleteRow, updateRow• When individual

functions are called, it uses the OVSDB client to perform transactions

• Also the conduit for all get calls for extracting DB data

c c

Row/NodeNotifications

New node, andTable monitorevents

Table update setOFController

Ovsdbconfigs

Get queries

Clienttransaction

Some operations are specific to Open vSwitch schema

Page 10: Using OVSDB and OpenFlow southbound plugins

MD-SAL OpenFlowPlugin

10

Page 11: Using OVSDB and OpenFlow southbound plugins

Data store at the Core

• Workflow for sending a packet_out‒ Data plugged into RPC calls that go through the datastore

‒ Both RPC and Data are modelled in Yang

Your application

Nicira Ext OF plugin

Nicira Ext OF Java

OpenFlowplugin

OpenFlowJava

Datastore

(1)

(2)

(3)

Switch1 Switch2 Switch3

Page 12: Using OVSDB and OpenFlow southbound plugins

Data store accessible through RestConf

12

Page 13: Using OVSDB and OpenFlow southbound plugins

Event Workflow

13

Page 14: Using OVSDB and OpenFlow southbound plugins

Modules Activated in Several Ways

• Old way: Bundle-Activator

‒ Bundle-Activator specified in pom.xml

‒ Activator class defined that either inherits from AbstractBindingAwareConsumer or ComponentActivatorAbstractBase

• New upcoming way: Config subsystem

‒ Uses yang modeling language as a language for modeling the configuration, dependencies and state data for Modules.

‒ For instance, in the l2switch repository, we see xml files that describe the different modules, MD-SAL dependencies and sequencing of loading:

./packethandler/config/src/main/resources/initial/50-packethandler.xml

./loopremover/config/src/main/resources/initial/52-loopremover.xml

./arphandler/config/src/main/resources/initial/54-arphandler.xml

./addresstracker/config/src/main/resources/initial/56-addresstracker.xml

./hosttracker/config/src/main/resources/initial/57-hosttracker.xml

./l2switch-main/config/src/main/resources/initial/58-l2switchmain.xml

14

Page 15: Using OVSDB and OpenFlow southbound plugins

App Development

15

Page 16: Using OVSDB and OpenFlow southbound plugins

OVSDB Plugin

Library

OpenvSwitchSchema

Your application

Nicira Ext OF plugin

Nicira Ext OF Java

OpenFlowplugin

OpenFlowJava

Your App

Let’s try https://github.com/sdnhub/SDNHub_Opendaylight_Tutorial/