Southbound plugins are essential for programming your network with OpenDaylight. In this meetup, we will discuss the plugins for OpenFlow and OVSDB, as well as the differences in writing applications with MD-SAL and AD-SAL. We will do bite-sized hands-on exercises to learn how to use the two plugins.
2. 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
ARP Handler
IListenDataPacket
L2 Learning s/w
Service Abstraction Layer (SAL)
OpenFlow
protocol plugin
OpenFlow
J
IPluginOutDataPacketService
IPluginInDataPacketService
OpenFlow
Switch1
Switch2
Switch3
IListenDataPacket
IDataPacketService
(1)
(2)
(3)
(3)
(5)
(4)
(6)
3. Intro to AD-SAL (API-driven SAL)
• 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
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);
}
4. Intro to MD-SAL (Model-driven SAL)
• Data store and access models is core of the worflow
4
9. OVSDB Plugin Main Impl Classes
9
Connection
Service
Row/Node
Notifications
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
New node, and
Table monitor
events
Table update setOFController
Ovsdb
configs
Get
queries
Client
transaction
Some operations are specific
to Open vSwitch schema
11. 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
OpenFlow
plugin
OpenFlow
Java
Datastore
(1)
(2)
(3)
Switch1 Switch2 Switch3
14. 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