Angelo Corsaro, PhD Chief Technology Officer
Looking at SDN with DDS Glasses
Cop
yrig
ht P
rism
Tech
, 201
4
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
Software Defined Networking
Cop
yrig
ht P
rism
Tech
, 201
4
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.
Northbound API
Cop
yrig
ht P
rism
Tech
, 201
4
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
Southbound API
OpenFlow
Cop
yrig
ht P
rism
Tech
, 201
4
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 Overview
Cop
yrig
ht P
rism
Tech
, 201
4
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
Cop
yrig
ht P
rism
Tech
, 201
4
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 Switch
Cop
yrig
ht P
rism
Tech
, 201
4The 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 Channel
Cop
yrig
ht P
rism
Tech
, 201
4
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
OpenFlow Messages
Cop
yrig
ht P
rism
Tech
, 201
4
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
Controller-to-Switch Messages
Cop
yrig
ht P
rism
Tech
, 201
4
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
Controller-to-Switch Messages
Cop
yrig
ht P
rism
Tech
, 201
4
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.
Asynchronous Messages
Cop
yrig
ht P
rism
Tech
, 201
4
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.
Symmetric Messages
OpenFlow Limitations
Cop
yrig
ht P
rism
Tech
, 201
4
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
Discovery
Cop
yrig
ht P
rism
Tech
, 201
4
The OpenFlow standard currently support a single controller
Support for multiple simultaneous controllers is currently undefined
Fault-Tolerance
Cop
yrig
ht P
rism
Tech
, 201
4The 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
Error Management
Cop
yrig
ht P
rism
Tech
, 201
4
OpenFlow provides only a pull API to get statistics, with the implication that controllers are forced to periodically poll
Pull Statistics API
Cop
yrig
ht P
rism
Tech
, 201
4
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
One-to-One Communication
Cop
yrig
ht P
rism
Tech
, 201
4
OpenFlow does not apply the “SDN” philosophy to itself, i.e., it does not clearly separates the data-plane from the control plane
Data/Control Plane Separation
Northbound API
Cop
yrig
ht P
rism
Tech
, 201
4
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
Northbound API
Cop
yrig
ht P
rism
Tech
, 201
4
Floodlight REST APIURI 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>/json
GET List of traffic counters per switch
/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.
Cop
yrig
ht P
rism
Tech
, 201
4
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/
DELETEAdd/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/
DELETECreates 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/
DELETEGET: None "POST: {"<field 1>":"<value 1>", "<field 2>":"<value 2>", ...} "DELETE: {"<ruleid>":"<int>"}
Architectural Considerations
Cop
yrig
ht P
rism
Tech
, 201
4
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
Architectural Considerations
Controller
App1 App2 Appn
Switch1 Switch2 SwitchK
DDS Overview
DDS is a standard technology for ubiquitous, interoperable, secure, platform independent, and real-time data sharing across network connected
devices
Cop
yrig
ht P
rism
Tech
, 201
4
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
Data Distribution Service (DDS)
DDS Global Data Space
...
Data Writer
Data Writer
Data Writer
Data Reader
Data Reader
Data Reader
Data Reader
Data Writer
TopicAQoS
TopicBQoS
TopicCQoS
TopicDQoS
Cop
yrig
ht P
rism
Tech
, 201
4DataWriters 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
Data Distribution Service (DDS)
DDS Global Data Space
...
Data Writer
Data Writer
Data Writer
Data Reader
Data Reader
Data Reader
Data Reader
Data Writer
TopicAQoS
TopicBQoS
TopicCQoS
TopicDQoS
Cop
yrig
ht P
rism
Tech
, 201
4
Fully Distributed Data Space
Conceptual Model Actual Implementation
Data Writer
Data Writer
Data Writer
Data Reader
Data Reader
Data Reader
Data Writer
TopicAQoS
TopicBQoS
TopicCQoS
TopicDQoS
TopicDQoS
TopicDQoS
TopicAQoS
DDS Global Data Space
...
Data Writer
Data Writer
Data Writer
Data Reader
Data Reader
Data Reader
Data Reader
Data Writer
TopicAQoS
TopicBQoS
TopicCQoS
TopicDQoS
Cop
yrig
ht P
rism
Tech
, 201
4
Data Writer
Data Writer
Data Writer
Data Reader
Data Reader
Data Reader
Data Writer
TopicAQoS
TopicBQoS
TopicCQoS
TopicDQoS
TopicDQoS
TopicDQoS
TopicAQoS
Fully Distributed Data SpaceThe communication between the DataWriter and the DataReader can use UDP/IP (Unicast and Multicast)or TCP/IP
Cop
yrig
ht P
rism
Tech
, 201
4
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
Cop
yrig
ht P
rism
Tech
, 201
4
Content and Temporal Filtering (both sender and receiver filtering supported)
Queries
20+ QoS to control existential, temporal, and spatial properties of data
Key Highlights
DDS Based SDN
Cop
yrig
ht P
rism
Tech
, 201
4
DDS can be leveraged to:
Separate Data Plane from the Control Plane of the SDN Controller
Enable distributed Controller architecture
Improve Scalability
Discovery
DDS-Based SDN
Cop
yrig
ht P
rism
Tech
, 201
4Existing 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
Cop
yrig
ht P
rism
Tech
, 201
4
DDSing OpenFlow
Switch
OpenFlow
Control DataDDS Adapter
Monitoring/Status Topics
Control Topics
Switch
OpenFlow
DataDDS Adapter
Monitoring/Status Topics
Control
Case 1 Case 2
Cop
yrig
ht P
rism
Tech
, 201
4
!
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
DDS Based SDN
ControllerM
App1 App2 Appn
Switch1 Switch2 SwitchK
DDS
Controller1
Cop
yrig
ht P
rism
Tech
, 201
4Multiple controller can be more easily supported
Controllers don’t need to behave as store-and-forward when not adding value
DDS Based SDN
ControllerM
App1 App2 Appn
Switch1 Switch2 SwitchK
DDS
Controller1
Cop
yrig
ht P
rism
Tech
, 201
4
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
DDS Based SDN
ControllerM
App1 App2 Appn
Switch1 Switch2 SwitchK
DDS
Controller1
Cop
yrig
ht P
rism
Tech
, 201
4
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
DDS Based SDN
ControllerM
App1 App2 Appn
Switch1 Switch2 SwitchK
DDS
Controller1
Sample Mapping OpenFlow on DDS
Cop
yrig
ht P
rism
Tech
, 201
4
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
Controller-to-Switch Messages
struct ofp_table_mod { struct ofp_header header; uint8_t table_id; uint8_t pad[3]; uint32_t config; };
Cop
yrig
ht P
rism
Tech
, 201
4
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
Asynchronous Messages
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]; };
Unleashing Data
Cop
yrig
ht P
rism
Tech
, 201
4
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
OpenSpliceEnterprise
Recommended
