SDN programming and operations requires continuous monitoring of network and application state as well as consistent configuration and update of (forwarding) policies across heterogeneous devices. This is resulting in significant challenges. Multiple open protocols such as OpenFlow, OF-CONFIG, OnePK , etc. are being adopted by different vendors causing an integration problem for developers. Internet of Things applications are pushing the size and volume of data handled by SDN systems demanding more efficient and scalable protocols for information distribution and coordination of SDN devices. This presentation will describe these and other SDN challenges and ways in which various open protocols, such as DDS, XMPP, AMQP, are being used to address them.

1. Your systems. Working as one.
Pardo‐Real‐Co‐Protocol and Integration Challenges for SDN
Gerardo Pardo Pardo‐‐Castellote Castellote, Ph.D.
, CTO, Real Real‐‐Time Innovations, Inc.
Co Co‐‐Chair OMG DDS SIG
Core Nervous System for The Industrial IoT

3. The hidden Plumbing

4. NFV and SDN
•
Evolution of network services from appliance to a virtual compute/network/storage model
4
Controller
Network Application & Orchestration
Data plane elements
(virtual and physical switches)
Northbound
Southbound
Control + Monitor
Business orchestration
Traffic engineering
Service Abstraction Layer
Connectivity Fabric

5. Example:
OpenDaylight (Cisco)
5
OpenDaylight Controller
Network Application & Orchestration
Data plane elements
(virtual and physical switches)
REST/HTTP
OpenFlow,
BGP
SNMP, Netconf

6. Example:
OpenContrail (Juniper)
Contrail Controller
Network Application & Orchestration
Data plane elements
(virtual and physical switches)
REST/HTTP
XMPP,
BGP
SNMP, Netconf

7. A Middleware perspective
Monitoring
Controller
Controller
Network App & Orchestration
Virtual/Physical switch
Northbound Middleware
Southbound Middleware
Analytic s
Virtual/Physical switch
Virtual/Physical switch

8. Enabling app stores
Controller
Controller
Virtual/Physical switch
Northbound Middleware
Southbound Middleware
Virtual/Physical switch
Virtual/Physical switch
Standardized Northbound
Information Model
Monitoring
Network App & Orchestration
Analytic s

9. Opening all the layers
Controller
Controller
Virtual/Physical switch
Northbound Middleware
Southbound Middleware
Virtual/Physical switch
Standardized Northbound
Information Model
Standardized
Southbound
Information Model
Monitoring
Network App & Orchestration
Analytic s

10. Do we really need 2 separate
communication planes?
Controller
Controller
Virtual/Physical switch
Virtual/Physical switch
Standardized
Northbound
Information Model
Standardized
Southbound
Information Model
Monitoring
Network App
& Orchestration
Analytic s
New capabilities

11. 11
How many
Virtual devices
Need to be
Monitored/Controlled
within a single
admin domain?
1000s?
10000?
1000000?
Are the Northbound/Southbound
protocols and middleware
Technologies ready for this?

12. Table 1: Near-term end-point differences between IIoT and HIoT Attribute Industrial IoT (IIoT) Human IoT (HIoT) Market Opportunity Brownfield Greenfield Product Lifecycle Until dead or obsolete Whims of style and/or budget Solution Integration Heterogeneous APIs Vertically integrated Security Access Identity & privacy Human Interaction Autonomous Reactive Availability 0.9999 to 0.99999 (4–5 ‘9’s) 0.99 to 0.999 (2–3 ‘9’s) Access to Internet Intermittent to independent Persistent to interrupted Response to Failure Resilient, fail-in-place Retry, replace Network Topology Federations of peer-to-peer Constellations of peripherals Physical Connectivity Legacy & purpose-built Evolving broadband & wireless Example Gateways Commercial monitoring Echelon SmartServer Consumer home automation Revolv Hub
http://www.moorinsightsstrategy.com/wp‐content/uploads/2013/10/Connecting‐with‐the‐Industrial‐Internet‐of‐Things‐IIoT‐by‐Moor‐Insights‐Strategy.pdf
Human internet vs Industrial Internet (M2M)

13. Taxonomy of protocol standards
•
Device Control protocols
–
Goal is to abstract & normalize interaction with network physical & virtual devices
•
OpenFlow, Netconf, BGP
•
Fit to function:
–
SNMP for Data Gathering and Monitoring
•
General communication messaging middleware with agreed usage
–
HTTP/REST, XMPP, AMQP, DDS‐RTPS, MQTT
13

14. SNMP
•
IETF RFC 3411 (SNMP version 3)
•
Purpose built to configure & monitor network devices
•
Extensible mechanism for device management:
–
Hierarchical tree of variables that can be read and written. Described via MIB
•
Simple READ/WRITE commands to variables + TRAP (notification) messages.
–
Binary (ASN.1) messages
–
Requires POLLING to get monitoring data
•
UDP based layered over DTLS and TLS for security
–
No secure multicast
14

15. Netconf
•
IETF RFC 4741 revised to RFC 6241
•
Purpose built to configure network devices
•
Request/Reply (RPC) & Support for notifications
–
All messages are XML
•
Connection‐oriented & point‐to point: TCP based
•
Security using SSH or TLS
–
No multicast
•
No automatic server discovery: Client must know address of all servers.
15

16. OpenFlow
•
Purpose built to configure forwarding rules on switches
–
Messages: controller‐to‐switch, asynchronous (notifications), symmetric
•
Connection‐oriented, point‐to point: TCP
–
Switch‐initiated connections
•
Binary messages.
•
No discovery. Manual configuration of IP addresses
•
Security by using TLS. No multicast
16

17. AMQP
•
General protocol for messaging. OASIS standard.
•
Model: Message flow between Nodes governed by rules. Can be made to support
–
Queues
–
Publish‐Subscribe
–
Content‐Filtering
•
Simple type‐system. Binary messages
•
Limited QoS
•
Needs Broker.
•
TCP‐based. TLS for security. No multicast
17

18. AMQP Architecture
•
All clients connect to broker
•
Brokers relay messages between clients
•
Brokers enforce point‐to‐point, queue, or pub‐sub based on exchange rules
AMQP
Broker

19. XMPP
•
General messaging protocol. IETF RFC 6120
•
Supports Point2Point, Pub/Sub, Queries, Discovery
•
Global resource addressability (JabberID)
–
Explicitly names server domain (e.g. jabber.org)
•
Brokered: 1 or 2‐hop brokers
–
Tied to Jabber‐ID servers
•
XML messages
•
No QoS
•
Connection‐oriented. TCP and TLS.
19

20. XMPP Architecture
jabber.org
rti.com
Bob
bob@jabber.org
Alice
alice@rti.com
Rose
rose@rti.com
Joe
joe@jabber.org
Maria
maria@jabber.org
<message
to=“alice@rti.com/car”
from=“bob@jabber.org”>
<body>Hello</body>
</message>
Resource:
mobile
Resource:
car

21. XMPP Fitness to M2M
•
Strong Points
–
Global naming and addressing
–
Discovery and presence
–
Proven to scale to large number of nodes & resources
•
Weak points
–
Naming tied to topology
–
No QoS
–
No peer‐to‐peer
–
Performance (XML verbosity, relays, TCP)
21

22. DDS: Data
Data‐‐Centric Qos Qos‐‐Aware Pub Pub‐‐Sub Model
Persistence Service
Recording Service
Virtual, decentralized global data space
CRUD operations
Source (Key)
Speed
Power
Phase
WPT1
37.4
122.0
-12.20
WPT2
10.7
74.0
-12.23
WPTN
50.2
150.07
-11.98

23. DDS
DDS‐‐RTPS Architecture
•
Peer‐to‐peer. No brokers
•
Pub/Sub or RPC logic co‐ located on each client application
•
Auto‐discovery & No servers => Zero configuration
RTPS

24. DDS Quality of Service (
QoS QoS)
QoS Policy
DURABILITY
HISTORY
LIFESPAN
WRITER DATA LIFECYCLE
READER DATA LIFECYCLE
ENTITY FACTORY
RESOURCE LIMITS
RELIABILITY
TIME BASED FILTER
DEADLINE
CONTENT FILTERS
Cache
User QoS
Delivery
Presentation
Availability
Resources
Transport
QoS Policy
USER DATA
TOPIC DATA
GROUP DATA
PARTITION
PRESENTATION
DESTINATION ORDER
OWNERSHIP
OWNERSHIP STRENGTH
LIVELINESS
LATENCY BUDGET
TRANSPORT PRIORITY

25. Fit
Fit‐‐to to‐‐function vs GP Messaging Middleware?
Similar to custom vs General Purpose Processors, Operating Systems, Servers…
•GP Encourages “ecosystems” and “app store” model
•GP Lowers cost, leverages community knowledge & skills, easier to find trained engineers
•GP may be less efficient and more complex than fit‐to‐purpose…
25

26. 26
create_local_datawri
ter_crypto_tokens
Binary
vs XML encoding?

27. UDP
vs TCP
•
TCP establishes reliable stream‐oriented point‐to‐ point connections
–
Each part of endpoints necessitates a connection
–
O(N2) sessions, sockets, ports, socket buffers
–
Enforces order and reliability.
•
Single flow: Head‐of‐line blocking
•
UDP is a datagram oriented connectionless protocol
–
No connections 1 socket to send to any. 1 socket to receive from any => O(N) resources
–
Best efforts reliability must be done by middleware
–
Supports Multicast
–
Multiple flows. Each packet independent of previous
27

28. Unicast
vs Multicast
28
Reliable Multicast
Unicast

29. Side
Side‐‐to to‐‐side
Model
Data
QoS
Transport
Security
Netconf
RPC & Notifications
XML/XSD
None
TCP & TLS
No Multicast
TLS
SNMP
Read/Write & Notifications
Binary / MIBs
None
UDP & DTLS
No Multicast
DTLS
OpenFlow
Point‐to‐Point
Binary
TLS
No Multicast
TLS
AMQP
Broker‐based
Queue and Pub‐Sub
Binary/Cust om Type System
2‐3
TCP & TLS
No Multicast
TLS
XMPP
Broker‐based
Point‐to‐point and pub‐sub
XML
None
TCP & TLS
No Multicast
TLS
DDS‐RTPS
Peer‐to‐peer
Pub‐Sub and RPC (*)
Binary,
IDL / XML/XSD
20+
UDP, Multicast,
TCP(*)
DDS‐Security
Fine‐grained Topic security
Secure Multicast

30. Thank You!!
©2014 Real‐Time Innovations, Inc. Confidential

31. Find out more
more……
www.rti.com
community.rti.com
demo.rti.com
www.youtube.com/realtimeinnovations
blogs.rti.com
www.twitter.com/RealTimeInnov
www.facebook.com/RTIsoftware
www.slideshare.net/GerardoPardo
dds.omg.org
www.omg.org
31