Software Defined Networking with Data Distribution Service

Angelo  Corsaro,  PhD  Chief  Technology  Officer  

[email protected]

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 PIs, 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 currently 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 from 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

4

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 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 lack any form of dynamic discovery

Switches are supposed to establish a connection with the controller at a user 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

4

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

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

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

Cop

yrig

ht P

rism

Tech

, 201

4