iCIS Summer Workshop, June 24-25, 2014 CoimbraI. Internet of Things
Torsten BraunUniversität [email protected], cds.unibe.chslideshare.net/torstenbraun
Overview
> Motivation and Introduction— Internet of Things (IoT) Architecture— Application Areas
> Web Services for IoT— IoT Protocol Stack— Resource-oriented IoT Architecture
> Constrained Application Protocol (CoAP)— Protocol Architecture and Features— HTTP-CoAP Mapping
> TCP/IP for IoT Devices— TCP/IP-based IoT Protocol Stacks— TCP and Distributed TCP Caching— IPv6 over Low power Wireless Personal Area Networks (6lowpan)— IPv6 Routing Protocol for Low-power and Lossy Networks (RPL)
> Energy-efficient Medium Access Control Layer Protocols— ContikiMAC— IEEE 802.15.4
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
2
Internet Evolution
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
3
Internet of Things (IoT)
In the IoT, things are objects of the physical world (physical things) or of the information world (virtual things), which are capable of being identified and integrated into information and communication networks. > Physical things exist in the physical world and
are capable of being sensed and/or actuated and/or connected. — Examples: sensors of surrounding environments, industrial robots,
goods, electrical equipment> Virtual things exist in the information world and
are capable of being stored, processed, and accessed. — Examples: multimedia contents, application software, and service
representations of physical things, e.g., avatars or virtual objects
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
4
IoT Challenges
> Interconnectivity of all things> Things-related services> Heterogeneity of devices’ hardware platforms and networks> Dynamic changes of devices states due to energy saving,
mobility, number of devices, wireless channels> Enormous scale: By 2020, one can expect 10s of billions
things to be managed and to communicate with each other
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
5
Layered IoT Architecture
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
6
IoT Application Areas
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
7
Web Services for IoT
> By using web service technology for smart object applications, existing — web-service-oriented systems, — programming libraries, and — knowledge can be directly applied to smart object applications.
> Smart object applications — can be directly integrated with existing business systems.— use the same interfaces and systems as existing business systems. — can be integrated into enterprise resource planning systems without
any intermediaries, thus reducing the complexity of the system as a whole.
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
8
Web Service Concept
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
9
IoT with Web Services
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
10
IoT with HTTP / CoAP
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
11
SOAP/REST
IoT Protocol Stack
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
12
Link Layer (e.g., IEEE 802.15.4)
IP
TCP UDP
HTTP CoAP
XML EXI JSON
Web Services
Representational State Transfer (REST)
> Representation— Data or resources are encoded as representations, e.g.,
– Resource: temperature– Representation: decimal number
> State— All of the necessary state needed to complete a request must be
provided with the request. — Clients and servers are stateless. — A client cannot rely on any state to be stored in the server, and
a server cannot rely on any state stored in the client. — This does not pertain to the data stored by servers or clients,
only to the connection state needed to complete transactions.> Transfer
— Representation and state to be transferred between client and serveriCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
13
Resource Oriented Architecture for IoT
REST is based on the notion of a resource to be used/addressed and has the following constraints: > Resource Identification
— Web relies on Uniform Resource Identifiers (URI) to identify resources. > Uniform Interface
— Resources should be available through a uniform interface with well-defined interaction semantics.→ HTTP with 4 main operations: GET, PUT, POST, DELETE
— Most web service applications offer RESTful interfaces. > Self-Describing Messages
— Web: HTML — Machine-oriented services: Media types such as the Extensible Markup
Language (XML) and JavaScript Object Notation (JSON) have gained widespread support across services and client platforms. Efficient XML Interchange (EXI) for constrained environments.
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
14
Data Formats for Web Services
XML JSON{"sensors":[{"name": "Temperature", "value": 26.1}]}
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
15
<xml><sensors>
<sensor><name>Temperature</name><value>27.1</value>
</sensor></sensors>
</xml>
REST Web Service Transfer
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
16
REST Web Service Transfer Example
> HTTP Request:GET /sensors/temperature HTTP/1.1Content-type: application/json
> HTTP Response: HTTP/1.1 200 OKContent-type: application/json{"sensors":[{"name": "Temperature", "value": 26.1}]}
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
17
REST Operations
> GET on http://.../spot1/sensors/temperature— returns the temperature observed by spot1,
i.e., it retrieves the current representation of the temperature resource.> PUT on http://.../sunspots/spot1/actuators/leds/1
— switches on the first LED of the SunSPOT, i.e., it updates the state of the LED resource.
> POST on http://.../spot1/sensors/temperature/rules— with a JSON representation of the rule as {“threshold”:35} encapsulated
in the HTTP body creates a rule that will notify the caller whenever the temperature is above 35 degrees.
> DELETE on http://.../spot— is used to shutdown the node.
> DELETE on http://.../spot1/sensors/temperature/rules/1— is used to remove rule number 1.
> OPTIONS to retrieve the operations that are allowed on a resource. — allows applications to find out what operations are allowed for any URI.— Example: an OPTIONS request on http://.../sunspots/spot1/sensors/tilt
returns GET, OPTIONS.iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
18
Constrained Application Protocol (CoAP)
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
19
> realizes a subset of HTTP functions> is optimized for constrained environments.> offers features such as built-in resource discovery,
multicast support, and asynchronous message exchange.> adopts datagram-oriented transport protocols such as UDP.> introduces a two-layer structure to
ensure reliable transmission over UDP. — Request/response interaction layer
to transmit resource operation requests and the request/response data.
— Message layer to deal with asynchronous interactions with UDP
CoAP Features
> constrained web protocol fulfilling machine-to-machine (M2M) requirements
> asynchronous message exchange> low header overhead and parsing complexity> URI and Content-type support> simple proxy and caching capabilities> optional resource discovery> UDP transport with optional reliability supporting unicast/multicast
(to query several devices simultaneously) requests> stateless HTTP-CoAP mapping, allowing proxy to provide
access to CoAP resources via HTTP and vice versa> security using Datagram Transport Layer Security (DTLS)
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
20
CoAP Message Layer
> to control message exchanges over UDP between two endpoints> Messages are identified by an ID to detect duplicates and to
provide reliability. > Message types
— Confirmable– requires a response, which can be piggybacked in an
acknowledgement or sent asynchronously in another message if the response takes too much time to be computed.
– Messages that cannot be processed are replied with a Reset message.— Non-Confirmable
– do not need to be neither acknowledged nor replied.— Acknowledgement
– confirm the reception of a confirmable message and can contain the piggybacked response to the confirmable message.
— Reset– if a confirmable message cannot be processed
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
21
CoAP Request/Response Interaction Layer
> Request and Response messages include method or response code.— A Request consists of the method that should be applied to the
resource, the identifier of the resource, a payload, an Internet media type (if any), an optional meta-data about the Request.
— A Response is identified by the code field in the CoAP header, which indicates the result of the Request.
— A Token Option is used to match Responses to Requests.> As CoAP is implemented over non-reliable transport,
it must implement reliability mechanisms.
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
22
CoAP Frame Format
> Version = 1 in the current version.> Type: (0) Confirmable, (1) Non-Confirmable, (2) Ack, (3) Reset.> Option Count:
4 bits indicating the number of options in the option header
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
23
CoAP Methods
> GET— retrieves a representation for the information corresponding to the
resource identified by the request URI.> POST
— requests the processing of the representation enclosed in the resource identified by the request URI. Normally it results in a new resource or the target resource being updated.
> PUT— requests that the resource identified by the request URI be updated
or created with the enclosed representation. > DELETE
— requests that the resource identified by the request URI be deleted.
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
24
CoAP Observe Functionality
> HTTP transactions are client-initiated: — A client must perform GET operations again and again (pulling),
if it wants to stay up to date about a resource’s status. — Pull model becomes expensive in a resource-limited environment
> CoAP uses an asynchronous approach to support pushing information from servers to clients: Observation.— In a GET request, a client can indicate its interest in further
updates from a resource by specifying the “Observe” option. — If the server accepts this option, the client becomes an observer
of this resource and receives an asynchronous notification message each time it changes.
— Each such notification message is identical in structure to the response to the initial GET request.
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
25
CoAP URIs
> CoAP URIs are very similar to HTTP URIs, providing the means to locate the resources.
> “coap:” “//” host [ “:” port ] path [ “?” query ]— The host can be provided either as an IP address, or a name,
which should be resolved using a resolution service such as DNS. — The port is the UDP port where the end-point is listening— The path defines the resource in that host. — The query in the form of “key=value” pairs enables parameterization
of the resource.
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
26
HTTP-CoAP Mapping
As CoAP implements a subset of the HTTP functionalities, there is a direct mapping between them. > CoAP-HTTP Mapping
— enables CoAP clients to access resources on HTTP servers through an intermediary. Mapping is straightforward, requiring the translation of HTTP Status codes to CoAP Response Codes.
> HTTP-CoAP Mapping — enables HTTP clients to access resources on CoAP servers
through an intermediary. Mapping requires filtering of those codes, options, and methods that are not supported by CoAP.
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
27
Web/WSN Integration by Proxies/Intermediaries
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
28
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
29
TCP/IP-based IoT Protocol Stacks
> Industry moves towards RFC-compliant, IPv6-based solutions> Transport either via UDP or TCP> Necessary translation between WSN nodes and Internet hosts
Transport Protocols
> Transport protocols such as TCP are used for — Congestion control— Error control: detection and recovery from packet loss to provide
of end-to-end reliability> Packet error rates in low-power wireless sensor networks
may easily be larger than 10 % due to the following reasons:— Low signal strength— High bit error rates (noisy channels)— Simultaneous transmissions (contention for the shared medium) — Self-interference / reflection / multi-path propagation— Queue overflow
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
30
TCP vs. non-TCP in WSNs
> Why not use TCP in WSNs? [previous decade]— TCP has been designed for the wired Internet and has been shown to
perform poorly for wireless multi-hop networks— TCP is unable to distinguish between congestion and transmission loss— TCP performs congestion control and error recovery only in endpoints.
Preprocessing or aggregation of data in intermediate nodes is desirable in sensor networks and often necessary
— TCP is heavyweight and “too big” for resource constrained WSN nodes > Why use TCP in WSNs? [current decade]
— TCP/IP protocol suite has become a global standard for communication— TCP implementation of µIP stack uses few kBytes— Congestion and error control can be transparently added.— Interoperability with IP-based technologies— ready solutions for naming, addressing, translation, lookup, discovery — ready solutions for end-to-end security
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
31
32
TCP Retransmissions
iCIS Summer Workshop, Coimbra, June 24, 2014 32
1 2 3 4 5 6 7 8 9 101
ACK 2
2
ACK 3
RTO expired, retransmit
Torsten Braun: Internet of Things
33
Distributed TCP Caching
1 2 3 4 5 6 7 8 9 10
ACK 1 (Sack 3)
123
ACK 4
2ACK 1 (Sack 2,3)
1
33iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
IPv6 in Wireless Sensor Networks
> IP in wireless sensor networks— Standard protocols and APIs— No need for protocol translation
> Proposal— IPv6 in networks with low-power devices and lossy wireless networks— IPv6 offers address space for massive deployment in small devices.
> Problems— Large transmission overhead by standard IPv6 header (40 bytes)— IPv6 requires minimum transmission unit (MTU) of 1280 bytes
while IEEE 802.15.4 limits the frame length to 128 bytes to ensure low packet error rate.
— Small devices such as sensors can not run complex routing protocols.— Low-power and lossy networks (LLNs) with temporary disruptions
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
34
IETF Working Groups
> IPv6 over Low power Wireless Personal Area Networks (6lowpan) WG — defines adaptation layer between IP and link layer (e.g., IEEE
802.15.4)— 6LowPAN: collection of nodes sharing the same IPv6 prefix
> Routing Over Low power and Lossy networks (roll) WG— defines requirements and specifies routing protocols for their use
in low power and lossy networks.— Example: IPv6 Routing Protocol for LLNs (RPL) supports
multipoint-to-point and point-to-multipoint traffic
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
35
IETF 6LoWPAN Adaptation Layer
> Header Compression— IPv6 Header Compression
– Certain fields in an IPv6 header, e.g., Version, Traffic Class, Flow Label, carry usual values.
– Payload Length can be inferred from link layer information.– IP addresses are inferred from MAC address, often link local
addresses.— UDP Header Compression
– Checksum elision– Port number compression by using ports of a certain range
> Fragmentation— Fragmentation into multiple link-level frames to accommodate
MTU requirement
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
36
IPv6 Routing Protocol for Low-power and Lossy Networks (RPL)> Routing protocol developed in IETF working group
“Routing Over Low-power and Lossy Networks” (ROLL)> Design issues
— lossy links— variable error rates— low resources (bandwidth and energy)
> RPL forms a Destination Oriented Directed Acyclic Graph (DODAG), with the root of the tree being the access point into the WSN— Distance vector protocol to build routes
from a node to root(s) of the network— Based on destination oriented directed
acyclic graphs (DODAGs)— Support of redundant paths by multiple DODAGs— DODAGs are maintained by root— Support of multipoint-to-point, point-to-multipoint, and
point-to-point traffic (via root)iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
37
RPL Operation
> Upward Routing— Directed Acyclic Graph (DAG) Information Object (DIO)
messages are broadcast periodically for discovery, formation and maintenance of DODAG tree.
— DIO includes – DODAG ID– Rank – ETX (Expected Transmission Count)
— Each node advertises ETX to the sink> Downward Routing
— Destination Advertisement Option (DAO) messages can be sent by leaf nodes to advertise path to root nodes.
— As a DAO message travels up the DODAG towards the root node, each node that it passes through appends its unique ID .
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
38
RPL Operation
0
1 1
3
2
22
1DIO DIO
DIO
DIO
DIO
DIODIO DIO
DIODIO
DIODIODIO
DIO
2
3 3 3
3
2
• Directed Acyclic Graph (DAG) Information Option (DIO) messages are broadcast to build the tree
• Rank has precedence, but ETX value decides which parent is chosen
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
39
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
40
Sources of Energy Waste in MAC Protocols
> Collisions and retransmissions> Idle listening to channel in order to
receive possible data > Transmission and reception are
similarly expensive, but much higher than active / idle CPU.
> Overhearing — occurs when nodes receive
packets destined to other nodes.— can be dominant in scenarios with
heavy load and high node density.> Control packet overhead> Overemitting
— transmission of a message when receiver is not ready
Example: TelosB
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
41
MAC Protocol Classification
1. Scheduled protocolsa) Polling
> Polling by central controller avoids energy waste caused by collisions but introduces polling overhead and delays
b) Multiplexing> Pre-allocation of channels based on time, frequency, or code multiplexing
— Advantage: inherently collision-free— Drawbacks
– well synchronized nodes throughout the network required– often: cluster formation required→ limited scalability and adaptivity, costly
maintenance2. Contention-based protocols
— Sharing of channels and channel allocation on-demand— Problem: inefficient usage of energy in case of contention
3. Hybrid approaches
ContikiMAC
integrates concepts of > B-MAC (low power listening)> X-MAC (packetized preamble)> BEAM / BoxMAC (data packets instead of preambles)> WiseMAC (estimation of receiver wakeup)
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
42
Unicast
Broadcast
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
43
Scheduled Protocols based on Clusters
> Formation of clusters with cluster head acting as base station. often: TDMA> Intra-cluster communication
— Nodes can only communicate with cluster head. > Inter-cluster communication
— Higher power level for inter-cluster communication to interconnect cluster heads— Special time slots (TDMA), frequencies (FDMA) or codes (CDMA)
> Limited scalability and adaptivity to changes of number of nodes— Nodes join/leave cluster: overhead by frame length adaptation and slot assignment— Throughput limitation for static allocation
> Option— Dynamic slot assignment → signaling
1 2 3 … N 1 2 3 … N
slot
frame
IEEE 802.15.4
> IEEE 802.15.4 specifies — Wireless Medium Access Control
(MAC) — Physical Layer (PHY)for Low-Rate Wireless Personal Area Networks (LR-WPANs)
> Contiki only uses 802.15.4 PHY Layer offered by radio hardware. Using 802.15.4 radios does not imply using their MAC layer.
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
44
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
45
IEEE 802.15.4-2006 MAC
> Coordinator defines optional super-frame structure with 16 equally sized slots.
> Beacons synchronize devices.> Slotted CSMA/CA protocol for contention access period> Transactions shall be completed until next beacon. > Super-frame may have active and inactive period.
Coordinator may enter low power mode during inactive period.> Coordinator may allocate up to 7 guaranteed time slots (GTS)> Non-beacon mode allows no duty cycling
contention access period
contention contention free period
inactiveperiod
IEEE 802.15.4e
> IEEE802.15.4e is an active working subgroup created 2008 to redesign the MAC protocol defined in IEEE802.15.4-2006
> Time Synchronized Channel Hopping> Average Duty Cycle of 1%> Requires synchronization across entire network> Channel hopping to avoid interferences:
— Time is divided into slots; — Absolute Slot Number (ASN) is incremented at each slot and
shared by all nodes. At each new slot, the frequency to be used is calculated as: frequency = (ASN + channelOffset) % 16
— channelOffset is a number between 0 and 15, which is assigned to each slot during reservation
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
46
Summary
> TCP/IP and energy-efficient MAC protocols for the IoT> CoAP as replacement for HTTP for resource-constrained nodes> Research moving to higher-layer and application issues
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Internet of Things
47
iCIS Summer Workshop, June 24-25, 2014 CoimbraII. Future Internet
Torsten BraunUniversität [email protected], cds.unibe.ch
Overview
> Software-Defined Networks (SDN)— Motivation and Introduction— Software Defined Networking Architecture— OpenFlow Protocol— SDN Applications
> Network Function Virtualization (NFV)— Use Cases— Architecture
> Information-Centric Networking (ICN)— Key Principles and Functions— Content-Centric Networking (CCN)— Publish-Subscribe Internet (PSI) Naming
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
2
Legacy Networking Technology Limitations
> Large set of various protocols, slow standardization> Buggy equipment software> Huge network operation costs> Risk of inconsistent policies and configurations> Scalability> Vendor dependence and closed equipment
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
3
• extremely complex• mainframe mentality• very expensive
Custom Forwarding Hardware
Operating System
Feature Feature
Routing, management, mobility management, access control, VPNs, …
Network Device Architecture
millions of lines of source code(based on > 6000 RFCs)
billions of power-hungry gates
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
4
Custom Hardware
Fea-ture
Fea-ture
Custom Hardware
Custom Hardware
Custom Hardware
Custom Hardware
OperatingSystem
OperatingSystem
OperatingSystem
OperatingSystem
Operating System
Network OS
Control Program Control Program
Fea-ture
Fea-ture
Fea-ture
Fea-ture
Fea-ture
Fea-ture
Fea-ture
Fea-ture
Restructuring Networks
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
5
• vertically integrated• closed, proprietary• slow innovation• small industry
specializedoperatingsystem
specializedhardware
Appspecializedapplications
• horizontal• open interfaces• rapid innovation• huge industry
microprocessor
open interface
Linux MacOSWindows or or
open interface
Mainframes
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
6
• vertically integrated• closed, proprietary• slow innovation
App
• horizontal• open interfaces• rapid innovation
controlplane
controlplane
controlplane or or
open interface
specializedcontrol plane
specializedhardware
specializedfeatures
merchantswitching chips
open interface
Routers
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
7
Traditional Computer Networks: Data Plane
data plane:packet handling
forward, filter, buffer, mark, rate-limit, measure packets
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
8
Traditional Computer Networks: Control Plane
track topology changes, compute routes, install forwarding rules
control plane:distributed algorithms
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
9
Traditional Computer Networks: Management Plane
collect measurements and configure equipment
management plane:human time scale
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
10
Software Defined Networking (SDN)
API to data plane(e.g., OpenFlow)
logically-centralized control
switches
smart,slow
dumb,fast
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
11
Architecture
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
12
Application Layer
Control Layer
Infrastructure Layer
Business Applications
SDNControlSoftware
Network Services
Network Device
API API API
Controller: Programmability
13
Network OS
Controller Application
Events from switches• topology changes• traffic statistics• arriving packets
Commands to switches• (un)install rules• query statistics• send packets
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
Distributed Controller
14
partition and replicate state→ scalability and reliabilityNetwork OS
Controller Application
Network OS
Controller Application
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
Data Plane: Simple Packet Handling
Simple packet-handling rules> Pattern: match packet header bits> Actions: drop, forward, modify, send to controller > Priority: disambiguate overlapping patterns> Counters: #bytes and #packets
(received, transmitted, dropped, erroneous, …)
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
15
MAC src MAC dst IP src IP dst TCP dst port … Action Count
* 10:20:. * * * * Port1 250* * * 5.6.7.8 * * Port2 300* * * * 25 * Drop 892* * * 192.* * * Local 120* * * * * * Controller 11
Network Devices
> Router— Match: longest destination IP prefix— Action: forward out via a link
> Switch— Match: destination MAC address— Action: forward or flood
> Firewall— Match: IP addresses and TCP/UDP port numbers— Action: permit or deny
> Network Address Translator— Match: IP address and port— Action: rewrite address and port
16iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
OpenFlow
> Most Ethernet switches and routers contain flow tables based on content addressable memory running at line-rate to— support QoS— implement firewalls and NATs— collect statistics
> Switches and routers provide similar functionality, but have proprietary flow tables (data path = flow table + actions)
> OpenFlow aims to provide a standard interface to program flow tables.
> OpenFlow switch 1. Flow / group / meter tables2. Secure channel for configuration 3. OpenFlow protocol
> OpenFlow Controller — adds/changes/removes table entries.
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
17
OpenFlowController
(secure)OpenFlowChannel
Group/MeterTable
FlowTable
FlowTable
OpenFlow protocol(SSL/TLS)
OpenFlow switch
pipeline
port
Operation
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
18
Flow Table
> Match fields: to match against packets, consisting of ingress port and packet headers
> Priority: matching precedence of flow entry> Counters: updated when packets are matched> Instructions: to modify action set or pipeline processing.> Timeouts: maximum amount of time or idle time
before flow is expired by switch.> Cookie: opaque data value chosen by controller
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
19
Switchport
MACsrc
MACdst
Ethtype
VLANID
IPsrc
IPdst
IPprot
srcport
dstport
VLANprio
MPLSlabel
MPLStraffic cl.
IP ToS
Priority Counters Instructions Timeouts CookieMatch Fields
Instructions
> Each flow table entry contains a set of instructions, which are executed when a packet matches the entry.
> Instructions change packet, action set and/or pipeline processing.> Required instructions
— Write-Actions: merges specified action into current action set— Goto-Table: indicates next table in processing pipeline
> Optional instructions— Meter: direct packet to specified meter— Apply-Actions: applies specified actions immediately— Clear-Actions: clear all actions immediately
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
20
Actions and Action Sets
> Actions— Decrementing/copying TTL values — Pop/push tags (MPLS, VLAN headers)— Set MAC/IP addresses, VLAN IDs, port numbers, IP header bits etc. — Quality-of-service support, e.g., assign queues to packet— Output of packets
> Action Sets— are empty at the beginning.— Flow entry instructions modify action set.— Execution of actions at the end of pipeline.
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
21
Packet Processing
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
22
Packet Flow
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
23
Group and Meter Table
> Group Table— Group: list of action buckets and some means to choose one or more
buckets per packet— Group table entry
– Group Identifier: 32 bit unsigned integer uniquely identifying the group– Group Type: to determine group semantics
– All: multicast or flooding– Select: multipath forwarding and load balancing– Indirect: simple indirection– Fast failover
– Counters: updated when packets are processed by a group– Action Buckets: an ordered list of action buckets, where each action bucket
contains a set of actions to execute and associated parameters> Meter Table
— Quality of Service operation— Rate limiting— metering
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
24
Group Identifier Group Type Counters Action Buckets
OpenFlow Protocol
> Message types— Controller-to-switch to
– request switch features– set and query configuration parameters– add, modify, delete flow / group / meter table entries– read switch statistics– output packets to switch
— Asynchronous: Unsolicited messages from switch to controller to– receive packets– indicate flow removal after timeout– indicate port status
— Symmetric– Hello messages– Echo messages– Error messages
> Connection setup— TLS/TCP connection
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
25
SDN Summary: Key Issues
> Separation of control plane from data plane> Centralized controller and centralized view of the network> Open interfaces between devices in the control plane
(controllers) and those in data plane (network devices)> Network programmability by external applications
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
26
SDN Summary: Benefits
> Simpler centralized network management and control — increases network reliability and — minimizes inconsistent configuration
> Improved automation and management by common APIs> Abstraction of underlying network details from
orchestration/provisioning systems and applications> Rapid innovation independent from network device
manufacturers> Programmability by operators and users> More fine-granular network control> Simpler, faster, cheaper network devices
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
27
SDN Applications
> Dynamic access control> Seamless mobility/migration> Server load balancing> Network virtualization> Link failure recovery> Data center networking > Multiple wireless access points> Energy-efficient networking> Adaptive traffic monitoring> Denial-of-Service attack detection> Network management and control> Virtual networks> Non-IP networks, Future Internet protocols> Deep-packet inspection, intrusion detection
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
28
Dynamic Access Control
> inspect first packet of a connection> consult access control policy> install rules to block or route traffic
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
29
Seamless Mobility/Migration
> see host to send traffic at new location> modify rules to reroute traffic
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
30
Server Load Balancing
> Pre-install load-balancing policy> Split traffic based on source IP
31
src=0*
src=1*
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
Network Virtualization
32
Controller #1 Controller #2 Controller #3
Partition space of packet headers
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
Network Function Virtualization (NFV)
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
33
NFV Use Cases
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
34
NFV Architecture
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
35
Operations/Business Support System
Element Management SystemVirtual Network Function
Management & Operation
Information-Centric Networking (ICN)
> Today’s network traffic is dominated by information retrieval rather than point-to-point communication between machines or humans.
> Circuit communication model is not considered as appropriate any more.
> Future communication architecture should focus on information objects instead of nodes.
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
36
Traditional Web Retrieval / Web Services
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
37
web server / web service
DNS server
search engine /service registry
user’s end system
Related Work
> Peer-to-Peer Networks— Construction of overlay networks— Content / service discovery,
e.g., using distributed hash tables, flooding, random walks, etc. > Web Caching
— Providing content for local users> Content Distribution Networks
— Routing and redirection of HTTP requests— Cache management
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
38
Key Principles and Functions
> Naming of content rather than hosts/interfaces— Content independent of devices that store it— Naming is location independent (mobility support !)
> Receivers (subscribers) request content> Senders (publishers) advertise content> Receivers and senders do not have to be aware of each other,
and are decoupled in time.> Functions needed
— Name resolution (rendezvous) to match subscriptions and publications
— Routing and path formation— Forwarding content from publisher to subscriber
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
39
Content Distribution
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
40
/unibe.ch/braun/talks/2014/icis
1
32
4 5 76
Naming Approaches
> Human-readable, hierarchical names— supports aggregation— needs coordination— Example: CCN
> Flat (self-certifying) names— Often based on hashing content name and/or owner’s public key— Aggregation more difficult— Example: PSI
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
41
Name Resolution and Data Transport
> Decoupled— Name resolution and data transport are independent of each other,
cf. DNS, with possibly different nodes for resolution and data transport— allows different, possibly already existing transport mechanisms,
also multi-path— Example: PSI
> Coupled— Nodes for both name resolution and data transport with inverse data
path compared to search path— rather disruptive technology— Local routing procedures advantageous in case of short link disruptions— Variants
– 2 phases: mapping of ID to locator, routing to data source – 1 phase: direct ID-based routing to data source
— Example: CCNiCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
42
Content-Centric Networking (CCN)
> Combination of content lookup and message routing> Idea: describe the users’ interests in the message header,
but not where to get it. > Messages (using XML encoding)
— Interest: content name, selector— Data: content name, signature (info), data
> Hierarchical content names— Example: /unibe.ch/braun/talks/2014/icis
> Related Projects— NDN = Named Data Networking, www.named-data.net— CCNx = Open Source Core Software Project for
Content-Centric Networking, www.ccnx.org
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
43
IP Model
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
44
FIB
FIB: Forwarding Information Base
Messages
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
45
Interest Message Data Message
Interest Message Processing
1. Longest prefix match on content name in Content Store (CS): returning data and discarding Interest
2. Pending Interest Table (PIT) match: adding request to PIT and discarding Interest
3. Forwarding Information Base (FIB) match: forwarding of Interest towards data— FIB population by announcements of content availability)
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
46
Match in Content Store
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
47
FIB
CS: Content StoreFIB: Forwarding Information BasePIT: Pending Interest Table
Name
CS
Name
Data
PIT
Match in Forwarding Information Base
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
48
FIBCS
Name
PIT
Match in Pending Interest Table
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
49
FIBCS
Name
PIT
x
Naming
> Any kind of names are possible → flexible naming> Examples
— /unibe.ch/braun/talks/2014/icis— /unibe.ch/E8/Room103/Projector
> Support for simple operations— %C1.org.ccnx.frobnicate~1~37— command in the namespace org.ccnx— operation is frobnicate, which takes 1 and 37 as arguments
> Naming resolution approach: coupled with 1 phase
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
50
Routing
> Longest Prefix Match Routing (as in IP)> But: different FIB entry semantics
— IP: IP address prefix will be reached via an outgoing interface for an existing FIB entry.
— CCN: Content name prefix might be reached via an outgoing interface for an existing FIB entry.
> FIB entries should be populated proactively for known content.> Alternatively, searching for content, e.g., using broadcasting
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
51
Transport
> Stateless operation with receiver control> Pipelining: multiple outstanding Interest messages> Reliability by local retransmissions in strategy layer> Hop-by-hop flow control> Sequence numbers in names
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
52
Security
> Signing of names and data in each packet> Denial-of-Service attacks are difficult: Combination of multiple
Interests and only 1 data packet per Interest
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
53
CCN Discussion
> Advantages— Automatic content distribution— Latency < 1 round-trip-time— Minimization of latency— Minimization of bandwidth— Local congestion control— Built-in security
> Drawbacks and problems— Routing — Hierarchical naming— Source mobility
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
54
Publish-Subscribe Internet (PSI) Naming
> Information items = files, streams, services> Each information item has its own name. > Names are unique (SID,RID) pairs
— Rendezvous Identifier (RID)– Fixed-length, (flat) bit string– produced by application
specific function, e.g., hashing— Scope Identifier (SID)
– Containers for information items
– Basis for access control– Sequence of RID-like strings– Each item may belong to
one or more scopes.> Scope hierarchy with information belonging to different scopes.
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
55
SId1 SId3
SId2 SId4 SId5
SId6
RId6 RId7 RId8
RId1 RId2 RId3RId4RId5
PSI Network Primitives
> Subscribe— used to express interest in information items— Users can subscribe to information items or scopes.
(SID/RID) must be known. > Publish
— used to announce information items or scopes
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
56
PSI Operation
> Information producer publishes information item to rendezvous system consisting of rendezvous points.
> Rendezvous points are responsible for certain scopes.> Information consumer subscribes to information item.> Rendezvous system
— matches announcements and subscriptions— triggers delivery from information producer to information consumer,
e.g. using OpenFlow > Various caching strategies: on-path, off-path, replication
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
57
publication
subscription
Path establishment
PSI Operation
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
58
Summary
> SDN allows better programmability of network functions and services.
> NFV with huge potential for future (mobile communication) networks, e.g., www.mobile-cloud-networking.eu
> ICN as hot research topic, but gradual deployment unsure
iCIS Summer Workshop, Coimbra, June 24, 2014
Torsten Braun: Future Internet
59