protocol and and integration integration for...
TRANSCRIPT
Your systems. Working as one.
Protocol and Integration Challenges for SDN
Gerardo Pardo‐Castellote, Ph.D.
CTO, Real‐Time Innovations, Inc.
Co‐Chair OMG DDS SIG
Protocol and Integration Challenges for SDNProtocol and Integration Challenges for SDN
Gerardo Gerardo PardoPardo‐‐CastelloteCastellote, Ph.D., Ph.D.
CTO, RealCTO, Real‐‐Time Innovations, Inc.Time Innovations, Inc.
CoCo‐‐Chair OMG DDS SIGChair OMG DDS SIG
Core Nervous System for The Industrial IoT
The hidden PlumbingThe hidden Plumbing
NFV and SDNNFV 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 + MonitorBusiness orchestrationTraffic engineering
Service Abstraction Layer
Connectivity Fabric
Example: Example: OpenDaylightOpenDaylight
(Cisco)(Cisco)
5
OpenDaylight
Controller
Network Application & Orchestration
Data plane elements(virtual and physical switches)
REST/HTTP
OpenFlow,BGPSNMP, Netconf
Example: Example: OpenContrailOpenContrail
(Juniper)(Juniper)
Contrail Controller
Network Application & Orchestration
Data plane elements(virtual and physical switches)
REST/HTTP
XMPP,BGPSNMP, Netconf
A Middleware perspectiveA Middleware perspective
Monitoring
ControllerController
Network App & Orchestration
Virtual/Physical
switch
Northbound MiddlewareNorthbound Middleware
Southbound MiddlewareSouthbound Middleware
Analytic
s
Virtual/Physical
switch
Virtual/Physical
switch
Enabling app storesEnabling app stores
ControllerController
Virtual/Physical
switch
Northbound MiddlewareNorthbound Middleware
Southbound MiddlewareSouthbound Middleware
Virtual/Physical
switch
Virtual/Physical
switch
Standardized NorthboundInformation Model
Standardized NorthboundInformation Model
MonitoringNetwork App & Orchestration Analytic
s
Opening all the layersOpening all the layers
ControllerController
Virtual/Physical
switch
Northbound MiddlewareNorthbound Middleware
Southbound MiddlewareSouthbound Middleware
Virtual/Physical
switch
Standardized NorthboundInformation Model
Standardized NorthboundInformation Model
Standardized
Southbound
Information Model
Standardized
Southbound
Information Model
MonitoringNetwork App & Orchestration Analytic
s
Do we really need 2 separate Do we really need 2 separate communication planes?communication planes?
ControllerController Virtual/Physical
switch
Virtual/Physical
switch
Standardized
Northbound
Information Model
Standardized
Northbound
Information Model
Standardized
Southbound
Information Model
Standardized
Southbound
Information Model
MonitoringNetwork App & Orchestration Analytic
s
New capabilities
11
How manyVirtual devicesNeed to beMonitored/Controlled within a single admin domain?
1000s?10000?1000000?
Are the Northbound/Southbound protocols and middlewareTechnologies ready for this?
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)
Taxonomy of protocol standardsTaxonomy 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
SNMPSNMP•
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
NetconfNetconf
•
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
OpenFlowOpenFlow
•
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
AMQPAMQP
•
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
AMQP ArchitectureAMQP Architecture
•
All clients connect to broker
•
Brokers relay messages
between clients•
Brokers enforce
point‐to‐point, queue, or pub‐sub
based on exchange rules
AMQPBroker
XMPPXMPP•
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
XMPP ArchitectureXMPP Architecture
jabber.orgjabber.org rti.comrti.com
<message to=“[email protected]/car”from=“[email protected]”>
<body>Hello</body></message>
<message to=“[email protected]/car”from=“[email protected]”>
<body>Hello</body></message>
Resource:mobile
Resource:mobile
Resource:car
Resource:car
XMPP Fitness to M2MXMPP 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
DDS: DataDDS: Data‐‐Centric Centric QosQos‐‐Aware PubAware Pub‐‐Sub ModelSub Model
Persistence
ServiceRecording
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
DDSDDS‐‐RTPS ArchitectureRTPS Architecture
•
Peer‐to‐peer. No brokers
•
Pub/Sub or RPC logic co‐ located on each client
application
•
Auto‐discovery & No servers => Zero
configuration
RTPS
DDS Quality of Service (DDS Quality of Service (QoSQoS))
QoS
Policy
DURABILITY
HISTORY
LIFESPAN
WRITER DATA LIFECYCLE
READER DATA LIFECYCLE
ENTITY FACTORY
RESOURCE LIMITS
RELIABILITY
TIME BASED FILTER
DEADLINE
CONTENT FILTERS
Cache
User Q
oS
Delivery
PresentationAvailability
Resources
TransportQoS
PolicyUSER DATA
TOPIC DATA
GROUP DATA
PARTITION
PRESENTATION
DESTINATION ORDER
OWNERSHIP
OWNERSHIP STRENGTH
LIVELINESS
LATENCY BUDGET
TRANSPORT PRIORITY
FitFit‐‐toto‐‐function function vsvs
GP Messaging GP Messaging Middleware?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
create_local_datawri
ter_crypto_tokens
Binary Binary vsvs
XML encoding?XML encoding?
UDP UDP vsvs
TCPTCP•
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
UnicastUnicast
vsvs
MulticastMulticast
28
Reliable Multicast
Unicast
SideSide‐‐toto‐‐sidesideModel Data QoS Transport Security
Netconf RPC &
Notifications
XML/XSD None TCP & TLSNo Multicast
TLS
SNMP Read/Write &
Notifications
Binary /
MIBs
None UDP & DTLSNo Multicast
DTLS
OpenFlow Point‐to‐Point Binary TLSNo Multicast
TLS
AMQP Broker‐basedQueue and
Pub‐Sub
Binary/Cust
om Type
System
2‐3 TCP & TLSNo Multicast
TLS
XMPP Broker‐basedPoint‐to‐point
and pub‐sub
XML None TCP & TLSNo Multicast
TLS
DDS‐RTPS Peer‐to‐peerPub‐Sub and
RPC (*)
Binary,IDL /
XML/XSD
20+ UDP,
Multicast,TCP(*)
DDS‐SecurityFine‐grained
Topic securitySecure Multicast
Thank You!!Thank You!!
©2014 Real‐Time Innovations, Inc. Confidential
Find out moreFind out 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