Internet of Things and Future Internet

iCIS Summer Workshop, June 24-25, 2014 CoimbraI. Internet of Things

Torsten BraunUniversität [email protected], cds.unibe.chslideshare.net/torstenbraun

mailto:[email protected]

http://cds.unibe.ch/

http://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 serveriCIS Summer Workshop, Coimbra, June 24, 2014


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.1Content-type: application/json

> HTTP Response: HTTP/1.1 200 OKContent-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.iCIS Summer Workshop, Coimbra, June 24, 2014


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 101

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)

123

ACK 4

2ACK 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)iCIS Summer Workshop, Coimbra, June 24, 2014


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

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



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



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

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



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 CoimbraII. Future Internet

Torsten BraunUniversität [email protected], cds.unibe.ch

mailto:[email protected]

http://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

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



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



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



7

Traditional Computer Networks: Data Plane

data plane:packet handling

forward, filter, buffer, mark, rate-limit, measure packets



8

Traditional Computer Networks: Control Plane

track topology changes, compute routes, install forwarding rules

control plane:distributed algorithms



9

Traditional Computer Networks: 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

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



Distributed Controller

14

partition and replicate state→ scalability and reliabilityNetwork OS


Network OS




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 tables2. Secure channel for configuration 3. OpenFlow protocol

> OpenFlow Controller — adds/changes/removes table entries.



17

OpenFlowController

(secure)OpenFlowChannel

Group/MeterTable

FlowTable

FlowTable

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

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



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



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: CCNiCIS Summer Workshop, Coimbra, June 24, 2014


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

http://www.named-data.net/

http://www.ccnx.org/

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 StoreFIB: Forwarding Information BasePIT: 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 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



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

http://www.mobile-cloud-networking.eu/