Internet of Things and Future Internet

iCIS Summer Workshop, June 24-25, 2014
Coimbra
I. Internet of Things
Torsten Braun
Universität Bern
braun@iam.unibe.ch, cds.unibe.ch
slideshare.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
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
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
5

Layered IoT Architecture
6

IoT Application Areas
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.
8

Web Service Concept
9

IoT with Web Services
10

IoT with HTTP / CoAP
11

SOAP/REST
IoT Protocol Stack
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 server
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.
14

Data Formats for Web Services
XML JSON
{"sensors":
[{"name": "Temperature", "value": 26.1}]
}
15
<xml>
<sensors>
<sensor>
<name>Temperature</name>
<value>27.1</value>
</sensor>
</sensors>
</xml>

REST Web Service Transfer
16

REST Web Service Transfer Example
> HTTP Request:
GET /sensors/temperature HTTP/1.1
Content-type: application/json
> HTTP Response:
HTTP/1.1 200 OK
Content-type: application/json
{"sensors":[{"name": "Temperature", "value": 26.1}]}
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.
18

Constrained Application Protocol (CoAP)
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)
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
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.
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
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.
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.
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.
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.
27

Web/WSN Integration by
Proxies/Intermediaries
28

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
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
31

32
TCP Retransmissions
iCIS Summer Workshop, Coimbra, June 24, 2014 32
1 2 3 4 5 6 7 8 9 10
1
ACK 2
2
ACK 3
RTO expired,
retransmit

33
Distributed TCP Caching
1 2 3 4 5 6 7 8 9 10
ACK 1 (Sack 3)
1
2
3
ACK 4
2
ACK 1 (Sack 2,3)
1
33iCIS Summer Workshop, Coimbra, June 24, 2014

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
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
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
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)
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 .
38

RPL Operation
0
1 1
3
2
2
2
1DIO
DIO
DIO
DIO
DIO
DIODIO DIO
DIODIO
DIO
DIODIO
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
39

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

41
MAC Protocol Classification
1. Scheduled protocols
a) 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
maintenance
2. 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)
42
Unicast
Broadcast

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.
44

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
inactive
period

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
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
47

iCIS Summer Workshop, June 24-25, 2014
Coimbra
II. Future Internet
Torsten Braun
Universität Bern
braun@iam.unibe.ch, 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
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
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
4

Custom
Hardware
Fea-
ture
Fea-
ture
Custom
Hardware
Custom
Hardware
Custom
Hardware
Custom
Hardware
Operating
System
Operating
System
Operating
System
Operating
System
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
5

• vertically integrated
• closed, proprietary
• slow innovation
• small industry
specialized
operating
system
specialized
hardware
App
specialized
applications
• horizontal
• open interfaces
• rapid innovation
• huge industry
microprocessor
open interface
Linux
Mac
OS
Windows or or
open interface
Mainframes
6

• vertically integrated
• closed, proprietary
• slow innovation
App
• horizontal
• open interfaces
• rapid innovation
control
plane
control
plane
control
plane
or or
open interface
specialized
control plane
specialized
hardware
specialized
features
merchant
switching chips
open interface
Routers
7

Traditional Computer Networks:
Data Plane
data plane:
packet handling
forward, filter, buffer, mark, rate-limit, measure packets
8

Control Plane
track topology changes, compute routes, install forwarding rules
control plane:
distributed algorithms
9

Management Plane
collect measurements and configure equipment
management plane:
human time scale
10

Software Defined Networking (SDN)
API to data plane
(e.g., OpenFlow)
logically-centralized control
switches
smart,
slow
dumb,
fast
11

Architecture
12
Application Layer
Control Layer
Infrastructure Layer
Business Applications
SDN
Control
Software
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

Distributed Controller
14
partition and replicate state
→ scalability and reliability
Network OS
Controller
Application
Network OS
Controller
Application

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, …)
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

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 tables
2. Secure channel for configuration
3. OpenFlow protocol
> OpenFlow Controller
— adds/changes/removes table entries.
17
OpenFlow
Controller
(secure)
OpenFlow
Channel
Group/
Meter
Table
Flow
Table
Flow
Table
OpenFlow protocol
(SSL/TLS)
OpenFlow switch
pipeline
port

Operation
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
19
Switch
port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
src
IP
dst
IP
prot
src
port
dst
port
VLAN
prio
MPLS
label
MPLS
traffic 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
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.
21

Packet Processing
22

Packet Flow
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
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
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
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
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
28

Dynamic Access Control
> inspect first packet of a connection
> consult access control policy
> install rules to block or route traffic
29

Seamless Mobility/Migration
> see host to send traffic at new location
> modify rules to reroute traffic
30

Server Load Balancing
> Pre-install load-balancing policy
> Split traffic based on source IP
31
src=0*
src=1*

Network Virtualization
32
Controller #1 Controller #2 Controller #3
Partition space of packet headers

Network Function Virtualization (NFV)
33

NFV Use Cases
34

NFV Architecture
35
Operations/Business Support System
Element Management System
Virtual 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.
36

Traditional Web Retrieval / Web Services
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
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
39

Content Distribution
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
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: CCN
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
43

IP Model
44
FIB
FIB: Forwarding Information Base

Messages
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)
46

Match in Content Store
47
FIB
CS: Content Store
FIB: Forwarding Information Base
PIT: Pending Interest Table
Name
CS
Name
Data
PIT

Match in Forwarding Information Base
48
FIBCS
Name
PIT

Match in Pending Interest Table
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
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
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
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
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
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.
55
SId1 SId3
SId2 SId4 SId5
SId6
RId6 RId7 RId8
RId1 RId2 RId3RId4
RId5

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
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
57
publication
subscription
Path establishment

PSI Operation
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
59

Internet of Things and Future Internet

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Internet of Things and Future Internet

Ähnlich wie Internet of Things and Future Internet (20)

Mehr von Torsten Braun, Universität Bern

Mehr von Torsten Braun, Universität Bern (19)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Internet of Things and Future Internet