Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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 
...
Copyright PrismTech, 2014 
Northbound API 
The northbound API interface enables applications and the overall management 
s...
Copyright PrismTech, 2014 
Southbound API 
The southbound API defines the programming interface between the controller 
an...
OpenFlow
Copyright PrismTech, 2014 
OpenFlow Overview 
The OpenFlow specification defines the 
components and the basic functions o...
Copyright PrismTech, 2014 
OpenFlow Switch 
An OpenFlow Switch consists of one or more 
flow tables and a group table, whi...
Copyright PrismTech, 2014 
OpenFlow Switch 
Each flow table in the switch contains a set of flow 
entries. Each flow entry...
Copyright PrismTech, 2014 
OpenFlow Channel 
The OpenFlow channel is the interface that 
connects each OpenFlow switches t...
Copyright PrismTech, 2014 
OpenFlow Messages 
The OpenFlow protocol supports three message types, controller-to-switch, 
a...
Copyright PrismTech, 2014 
Controller-to-Switch Messages 
Features: The controller may request the capabilities of a switc...
Copyright PrismTech, 2014 
Controller-to-Switch Messages 
Read-State: Read-State messages are used by the controller to co...
Copyright PrismTech, 2014 
Asynchronous Messages 
Packet-in: For all packets that do not have a matching flow entry, a pac...
Copyright PrismTech, 2014 
Symmetric Messages 
Hello: Hello messages are exchanged between the switch and controller upon ...
OpenFlow Limitations
Copyright PrismTech, 2014 
Discovery 
The current version of OpenFlow lack any form of dynamic discovery 
Switches are sup...
Copyright PrismTech, 2014 
Fault-Tolerance 
The OpenFlow standard currently support a single controller 
Support for multi...
Copyright PrismTech, 2014 
Error Management 
The OpenFlow API makes it hard to verify the success of certain commands as 
...
Copyright PrismTech, 2014 
Pull Statistics API 
OpenFlow provides only a pull API to get statistics, with the implication ...
Copyright PrismTech, 2014 
One-to-One Communication 
OpenFlow is designed for one-to-one communication. One to many intera...
Copyright PrismTech, 2014 
Data/Control Plane Separation 
OpenFlow does not apply the “SDN” philosophy to itself, i.e., it...
Northbound API
Copyright PrismTech, 2014 
Northbound API 
The northbound API provides the application tier with higher-level access to SD...
Copyright PrismTech, 2014 
Floodlight REST API 
URI Method Description 
/wm/core/switch/all/<statType>/json GET Retrieve a...
Copyright PrismTech, 2014 
Floodlight REST API 
/wm/device/ GET List of all devices tracked by the controller. This 
inclu...
Architectural 
Considerations
Copyright PrismTech, 2014 
Architectural Considerations 
Centralised architecture with a 
single controller 
South/Northbo...
DDS Overview
DDS is a standard technology for ubiquitous, 
interoperable, secure, platform independent, and 
real-time data sharing acr...
Copyright PrismTech, 2014 
Data Distribution Service (DDS) 
DDS provides a Global Data Space 
abstraction that allows appl...
Copyright PrismTech, 2014 
Data Distribution Service (DDS) 
DataWriters and DataReaders are 
automatically and dynamically...
Copyright PrismTech, 2014 
Fully Distributed Data Space 
Conceptual Model Actual Implementation 
Data 
Writer 
Data 
Write...
Copyright PrismTech, 2014 
Fully Distributed Data Space 
Data 
Writer 
Data 
Writer 
Data 
Writer 
Data 
Reader 
Data 
Rea...
Copyright PrismTech, 2014 
Key Highlights 
Elegant and High Level Data Sharing Abstraction 
Efficient and extensible Reque...
Copyright PrismTech, 2014 
Key Highlights 
Content and Temporal Filtering (both sender and receiver filtering supported) 
...
DDS Based SDN
Copyright PrismTech, 2014 
DDS-Based SDN 
DDS can be leveraged to: 
Separate Data Plane from the Control Plane of the SDN ...
Copyright PrismTech, 2014 
DDSing OpenFlow 
Existing OpenFlow-based switches can be easily extended to leverage DDS 
Two a...
Copyright PrismTech, 2014 
DDSing OpenFlow 
Monitoring/Status 
Control Data 
DDS 
Adapter 
OpenFlow 
Switch 
Topics 
Contr...
Copyright PrismTech, 2014 
DDS Based SDN 
! 
Dynamic discovery makes it 
very simple to configure, 
upgrade, and extend th...
Copyright PrismTech, 2014 
DDS Based SDN 
Multiple controller can be 
more easily supported 
Controllers don’t need to 
be...
Copyright PrismTech, 2014 
DDS Based SDN 
Status and configuration 
information can be made 
available as Transient topics...
Copyright PrismTech, 2014 
DDS Based SDN 
The controller can focus on 
enriching information as 
opposed to simply 
propag...
Mapping OpenFlow 
on DDS
Copyright PrismTech, 2014 
Controller-to-Switch Messages 
The state of the switch can be modelled as 
Transient Topics 
Up...
Copyright PrismTech, 2014 
Asynchronous Messages 
Asynchronous messages can be modelled as 
Transient, KeepAll topics 
The...
Unleashing Data
Copyright PrismTech, 2014 
The Vortex Platform 
Vortex enables seamless, 
ubiquitous, efficient and 
timely data sharing a...
Copyright PrismTech, 2014
Upcoming SlideShare
Loading in …5
×

Software Defined Networking with Data Distribution Service

1,647 views

Published on

The idea of programmable networks has recently re-gained momentum due to the emergence of Software-Defined Networking (SDN) and its promises to dramatically simplify network management and enable innovation. 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 while network applications communicate with the controller via the northbound-API.

While OpenFlow has emerged as one of the most widely adopted API for the southbound API, the situation is far more fragmented for the northbound API. This presentation will take a fresh look at northbound and southbound SDN interface requirements and will investigate the advantages that the OMG's Data Distribution Service standard can bring in terms of performance, scalability, and interoperability.

Published in: Software
  • Be the first to comment

Software Defined Networking with Data Distribution Service

  1. 1. Looking at SDN with DDS Glasses Angelo Corsaro, PhD Chief Technology Officer angelo.corsaro@prismtech.com
  2. 2. 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
  3. 3. Copyright PrismTech, 2014 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 PIs, with several dozen open and proprietary protocols being developed using different northbound APIs.
  4. 4. Copyright PrismTech, 2014 Southbound API 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
  5. 5. OpenFlow
  6. 6. Copyright PrismTech, 2014 OpenFlow Overview The OpenFlow specification defines the components and the basic functions of an “OpenFlow” switch along with the protocol it from a remote controller
  7. 7. Copyright PrismTech, 2014 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.
  8. 8. Copyright PrismTech, 2014 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
  9. 9. Copyright PrismTech, 2014 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
  10. 10. Copyright PrismTech, 2014 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
  11. 11. Copyright PrismTech, 2014 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
  12. 12. Copyright PrismTech, 2014 Controller-to-Switch Messages 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
  13. 13. Copyright PrismTech, 2014 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.
  14. 14. Copyright PrismTech, 2014 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.
  15. 15. OpenFlow Limitations
  16. 16. Copyright PrismTech, 2014 Discovery 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
  17. 17. Copyright PrismTech, 2014 Fault-Tolerance The OpenFlow standard currently support a single controller Support for multiple simultaneous controllers is currently undefined
  18. 18. Copyright PrismTech, 2014 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
  19. 19. Copyright PrismTech, 2014 Pull Statistics API OpenFlow provides only a pull API to get statistics, with the implication that controllers are forced to periodically poll
  20. 20. Copyright PrismTech, 2014 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
  21. 21. Copyright PrismTech, 2014 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
  22. 22. Northbound API
  23. 23. Copyright PrismTech, 2014 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
  24. 24. Copyright PrismTech, 2014 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.
  25. 25. Copyright PrismTech, 2014 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>"}
  26. 26. Architectural Considerations
  27. 27. Copyright PrismTech, 2014 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
  28. 28. DDS Overview
  29. 29. DDS is a standard technology for ubiquitous, interoperable, secure, platform independent, and real-time data sharing across network connected devices
  30. 30. Copyright PrismTech, 2014 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
  31. 31. Copyright PrismTech, 2014 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 DDS Global Data Space Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA TopicB TopicC TopicD
  32. 32. Copyright PrismTech, 2014 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 DDS Global Data Space Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA TopicB TopicC TopicD
  33. 33. Copyright PrismTech, 2014 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
  34. 34. Copyright PrismTech, 2014 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
  35. 35. Copyright PrismTech, 2014 Key Highlights Content and Temporal Filtering (both sender and receiver filtering supported) Queries 20+ QoS to control existential, temporal, and spatial properties of data
  36. 36. DDS Based SDN
  37. 37. Copyright PrismTech, 2014 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
  38. 38. Copyright PrismTech, 2014 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
  39. 39. Copyright PrismTech, 2014 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
  40. 40. Copyright PrismTech, 2014 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 Switch1 Switch2 SwitchK Controller1
  41. 41. Copyright PrismTech, 2014 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 Switch1 Switch2 SwitchK Controller1
  42. 42. Copyright PrismTech, 2014 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 Switch1 Switch2 SwitchK Controller1
  43. 43. Copyright PrismTech, 2014 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 Switch1 Switch2 SwitchK Controller1
  44. 44. Mapping OpenFlow on DDS
  45. 45. Copyright PrismTech, 2014 Controller-to-Switch Messages 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; };
  46. 46. Copyright PrismTech, 2014 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]; };
  47. 47. Unleashing Data
  48. 48. Copyright PrismTech, 2014 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
  49. 49. Copyright PrismTech, 2014

×