Looking at SDN with DDS Glasses

Looking at SDN
with DDS Glasses
Angelo
Corsaro,
PhD
Chief
Technology
Officer
angelo.corsaro@prismtech.com

Copyright PrismTech, 2014
Software Defined Networking
SDN decouples the forwarding
hardware from control decisions so
to make the latter programmable
The controller, implementing the
control plane, communicates with
the switching device through, what is
commonly referred as, the
southbound API
Network applications communicate
with the controller via the
northbound-API

Northbound API
The northbound API interface enables applications and the overall management
system to program the network and request services from it
No standards have been ratified for northbound APIs, with several dozen open
and proprietary protocols being developed using different northbound APIs.

Southbound API
The southbound API defines the programming interface between the controller
and the network switches
OpenFlow is one of the most widely accepted standard for the Southbound API

OpenFlow Overview
The OpenFlow specification defines the
components and the basic functions of an
“OpenFlow” switch along with the protocol it
uses to communicate with a remote controller

OpenFlow Switch
An OpenFlow Switch consists of one or more
flow tables and a group table, which perform
packet lookups and forwarding, and an
OpenFlow channel to an external controller
The controller manages the switch via the
OpenFlow protocol
Using this protocol, the controller can add,
update, and delete flow entries, both
reactively (in response to packets) and
proactively

OpenFlow Switch
Each flow table in the switch contains a set
of flow entries. Each flow entry consists of
match fields, counters, and a set of
instructions to apply to matching packets
If no match is found in a flow table, the
outcome depends on switch configuration:
- the packet may be forwarded to the
controller over the OpenFlow channel
- dropped
- or may continue to the next flow table

OpenFlow Channel
The OpenFlow channel is the interface that
connects each OpenFlow switches to a controller
Through this interface, the controller configures
and manages the switch, receives events from the
switch, and sends packets out the switch

OpenFlow Messages
The OpenFlow protocol supports three message types, controller-to-switch,
asynchronous, and symmetric
Controller-to-switch messages are initiated by the controller and used to
directly manage or inspect the state of the switch
Asynchronous messages are initiated by the switch and used to update the
controller of network events and changes to the switch state
Symmetric messages are initiated by either the switch or the controller and sent
without solicitation

Controller-to-Switch Messages
Features: The controller may request the capabilities of a switch by sending a
features request; the switch must respond with a features reply that specifies the
capabilities of the switch. This is commonly performed upon establishment of
the OpenFlow channel.
Configuration: The controller can set and query configuration parameters in
the switch
Modify-State: Modify-State messages are sent by the controller to manage state
on the switches. Their primary purpose is to add/delete and modify flows/
groups in the OpenFlow tables and to set switch port properties

Read-State: Read-State messages are used by the controller to collect statistics
from the switch.
Packet-out: Used by the controller to send packets out of a specified port on the
switch, and to forward packets received via Packet-in messages
Barrier: Barrier request/reply messages are used by the controller to ensure
message dependencies have been met or to receive notifications for completed
operations

Asynchronous Messages
Packet-in: For all packets that do not have a matching flow entry, a packet-in event
may be sent to the controller (depending on the table configuration)
Flow-Removed: When a flow entry is added to the switch by a flow modify message,
an idle timeout value indicates when the entry should be removed due to a lack of
activity, as well as a hard timeout value that indicates when the entry should be
removed, regardless of activity. The flow modify message also specifies whether the
switch should send a flow removed message to the controller when the flow expires.
Port-status: The switch is expected to send port-status messages to the controller as
port configuration state changes. These events include change in port status events
(for example, if it was brought down directly by a user).
Error: The switch is able to notify the controller of problems using error messages.

Symmetric Messages
Hello: Hello messages are exchanged between the switch and controller upon
connection startup.
Echo: Echo request/reply messages can be sent from either the switch or the
controller, and must return an echo reply. They can be used to measure the
latency or bandwidth of a controller-switch connection, as well as verify its
liveness.
Experimenter: Experimenter messages provide a standard way for OpenFlow
switches to offer additional functionality within the OpenFlow message type
space. This is a staging area for features meant for future OpenFlow revisions.

Discovery
The current version of OpenFlow lacks any form of dynamic discovery
Switches are supposed to establish a connection with the controller at a
configurable IP address and port number

Fault-Tolerance
The OpenFlow standard currently support a single controller
Support for multiple simultaneous controllers is currently undefined

Error Management
The OpenFlow API makes it hard to verify the success of certain commands as
the controller does not receive success notification
An example is the FlowMod command, for errors are reported asynchronously
but not success. Thus asynchronous execution of commands can make it very
hard to deal with complex flow set-up

Pull Statistics API
OpenFlow provides only a pull API to get statistics, with the implication that
controllers are forced to periodically poll

One-to-One Communication
OpenFlow is designed for one-to-one communication. One to many interactions,
e.g. one switch toward multiple controllers, is not currently supported nor easy
to transparently and efficiently support

Data/Control Plane Separation
OpenFlow does not apply the “SDN” philosophy to itself, i.e., it does not clearly
separates the data-plane from the control plane

Northbound API
The northbound API provides the application tier with higher-level access to SDN
switches along with statistics and aggregated information
As an example let’s consider the Floodlight Northbound API

Floodlight REST API
URI Method Description
/wm/core/switch/all/<statType>/json GET Retrieve aggregate stats across all switches
/wm/core/switch/<switchId>/<statType>/json GET Retrieve per switch stats
/wm/core/controller/switches/json GET List of all switch DPIDs connected to the controller
/wm/core/controller/summary/json GET Controller summary (# of Switches, # of Links, etc)
/wm/core/counter/<counterTitle>/json GET List of global traffic counters in the controller (across all switches)
/wm/core/counter/<switchId>/<counterName>/
GET List of traffic counters per switch
json
/wm/core/memory/json GET Current controller memory usage
/wm/core/health/json GET Status/Health of REST API
/wm/core/systen/uptime/json GET Controller uptime
/wm/topology/links/json GET List all the inter-switch links. Note that these are only for switches connected
to the same controller. This is not available in the 0.8 release.
/wm/topology/switchclusters/json GET List of all switch clusters connected to the controller. This is not available in
the 0.8 release.

Floodlight REST API
/wm/device/ GET List of all devices tracked by the controller. This
includes MACs, IPs, and attachment points.
/wm/staticflowentrypusher/json POST/
DELETE
Add/Delete static flow
/wm/staticflowentrypusher/list/<switch>/json GET List static flows for a switch or all switches
/wm/staticflowentrypusher/clear/<switch>/json GET Clear static flows for a switch or all switches
/networkService/v1.1/tenants/<tenant>/networks/<network> PUT/POST/
DELETE
Creates a new virtual network. Name and ID
are required, gateway is optional.
/networkService/v1.1/tenants/<tenant>/networks/<network>/ports/
<port>/attachment
PUT/DELETE Attaches a host to a virtual network.
/networkService/v1.1/tenants/<tenant>/networks GET Shows all networks and their gateway, ID, and
hosts mac in json format.
/wm/firewall/module/<op>/json GET
/wm/firewall/rules/json GET/POST/
DELETE
GET: None "
POST: {"<field 1>":"<value 1>", "<field
2>":"<value 2>", ...} "
DELETE: {"<ruleid>":"<int>"}

Architectural Considerations
Centralised architecture with a
single controller
South/Northbound Pull status and
monitoring APIs
Analytics are centralised on the
controller
Controller, behaves in some cases as
store and forward
App1 App2 Appn
Controller
Switch1 Switch2 SwitchK

DDS is a standard technology for ubiquitous,
interoperable, secure, platform independent, and
real-time data sharing across network connected
devices

Data Distribution Service (DDS)
DDS provides a Global Data Space
abstraction that allows applications to
autonomously, anonymously,
securely and efficiently share data
DDS’ Global Data Space is fully
distributed, highly efficient and
scalable
QoS
QoS
...
QoS
QoS
DDS Global Data Space
Data
Writer
Data
Writer
Data
Writer
Data
Reader
Data
Reader
Data
Reader
Data
Reader
Data
Writer
TopicA
TopicB
TopicC
TopicD

Data Distribution Service (DDS)
DataWriters and DataReaders are
automatically and dynamically
matched by the DDS Discovery
A rich set of QoS allows to control
existential, temporal, and spatial
properties of data
QoS
QoS
...
QoS
QoS
Data
Writer
Data
Writer
Data
Writer
Data
Reader
Data
Reader
Data
Reader
Data
Reader
Data
Writer
TopicA
TopicB
TopicC
TopicD

Fully Distributed Data Space
Conceptual Model Actual Implementation
Data
Writer
Data
Writer
Data
Writer
Data
Reader
Data
Reader
Data
Reader
Data
Writer
QoS
QoS
TopicA
QoS
TopicB
QoS
TopicC
QoS
QoS
TopicD
TopicD
TopicD
QoS
TopicA
QoS
QoS
...
QoS
QoS
Data
Writer
Data
Writer
Data
Writer
Data
Reader
Data
Reader
Data
Reader
Data
Reader
Data
Writer
TopicA
TopicB
TopicC
TopicD

Fully Distributed Data Space
Data
Writer
Data
Writer
Data
Writer
Data
Reader
Data
Reader
Data
Reader
Data
Writer
QoS
QoS
TopicA
QoS
TopicB
QoS
TopicC
QoS
QoS
TopicD
TopicD
TopicD
QoS
TopicA
The
communication
between
the
DataWriter
and
the
DataReader
can
use
UDP/IP
(Unicast
and
Multicast)or
TCP/IP

Key Highlights
Elegant and High Level Data Sharing Abstraction
Efficient and extensible Request/Reply (RPCoDDS)
Polyglot and platform independent
• Java, Scala, C, C++, C#, JavaScript, CoffeeScript etc.
• Android, Windows, Linux, VxWorks, etc.
Peer-to-Peer by nature, Brokered when useful

Key Highlights
Content and Temporal Filtering (both sender and receiver filtering supported)
Queries
20+ QoS to control existential, temporal, and spatial properties of data

DDS-Based SDN
DDS can be leveraged to:
Separate Data Plane from the Control Plane of the SDN Controller
Enable distributed Controller architecture
Improve Scalability
Discovery

DDSing OpenFlow
Existing OpenFlow-based switches can be easily extended to leverage DDS
Two approaches are possible
- Case 1: Leverage DDS only to share status and monitoring information
- Case 2: Use DDS for both control and status/monitoring information

DDSing OpenFlow
Monitoring/Status
Control Data
DDS
Adapter
OpenFlow
Switch
Topics
Control
Topics
Monitoring/Status
Data
DDS
Adapter
OpenFlow
Switch
Topics
Control
Case 1 Case 2

DDS Based SDN
!
Dynamic discovery makes it
very simple to configure,
upgrade, and extend the
system
Pub/Sub makes it trivial to
distribute information to any
number of consumers
ControllerM
App1 App2 Appn
DDS
Controller1

DDS Based SDN
Multiple controller can be
more easily supported
Controllers don’t need to
behave as store-and-forward
when not adding value
ControllerM
App1 App2 Appn
DDS
Controller1

DDS Based SDN
Status and configuration
information can be made
available as Transient topics
to ensure that late joiner can
receive it
Monitoring information can
be distributed to interested
parties w/o having to be
concerned with the number
of consumers
ControllerM
App1 App2 Appn
DDS
Controller1

DDS Based SDN
The controller can focus on
enriching information as
opposed to simply
propagate it
Analytics can be now taken-out
of the controller which
focuses only on “control-plane”
matters
Analytics becomes simply an
application
ControllerM
App1 App2 Appn
DDS
Controller1

Sample Mapping
OpenFlow on DDS

The state of the switch can be modelled as
Transient Topics
Updating the state can be modelled as
simple writes or by using RPCoDDS
The type of the topic could be exactly the
same as the one specified by OpenFlow
struct
ofp_table_mod
{
struct
ofp_header
header;
uint8_t
table_id;
uint8_t
pad[3];
uint32_t
config;
};

Asynchronous Messages
Asynchronous messages can be modelled as
Transient, KeepAll topics
The type of the topic could be exactly the same
as the one specified by OpenFlow
struct
ofp_packet_in
{
struct
ofp_header
header;
uint32_t
buffer_id;
uint32_t
in_port;
uint32_t
in_phy_port;
uint16_t
total_len;
uint8_t
reason;
uint8_t
table_id;
uint8_t
data[0];
};

The Vortex Platform
Vortex enables seamless,
ubiquitous, efficient and
timely data sharing across
mobile, embedded, desktop,
cloud and web applications
Vortex is based on the OMG
DDS standard
OpenSplice
Enterprise

Looking at SDN with DDS Glasses

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Looking at SDN with DDS Glasses

Similar to Looking at SDN with DDS Glasses (20)

More from Angelo Corsaro

More from Angelo Corsaro (20)

Recently uploaded

Recently uploaded (20)

Looking at SDN with DDS Glasses