Your SlideShare is downloading. ×
0
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Internet of Things and Future Internet
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Internet of Things and Future Internet

608

Published on

iCIS summer workshop Coimbra 2014

iCIS summer workshop Coimbra 2014

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
608
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
62
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 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
  • 2. 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
  • 3. Internet Evolution iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Internet of Things 3
  • 4. 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
  • 5. 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
  • 6. Layered IoT Architecture iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Internet of Things 6
  • 7. IoT Application Areas iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Internet of Things 7
  • 8. 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
  • 9. Web Service Concept iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Internet of Things 9
  • 10. IoT with Web Services iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Internet of Things 10
  • 11. IoT with HTTP / CoAP iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Internet of Things 11
  • 12. 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
  • 13. 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 iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Internet of Things 13
  • 14. 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
  • 15. 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>
  • 16. REST Web Service Transfer iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Internet of Things 16
  • 17. 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}]} iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Internet of Things 17
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. 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
  • 26. 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
  • 27. 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
  • 28. Web/WSN Integration by Proxies/Intermediaries iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Internet of Things 28
  • 29. 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
  • 30. 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
  • 31. 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. 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 Torsten Braun: Internet of Things
  • 33. 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 Torsten Braun: Internet of Things
  • 34. 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
  • 35. 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
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. 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 iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Internet of Things 39
  • 40. 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
  • 41. iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Internet of Things 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
  • 42. 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
  • 43. 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
  • 44. 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
  • 45. 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 inactive period
  • 46. 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
  • 47. 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
  • 48. iCIS Summer Workshop, June 24-25, 2014 Coimbra II. Future Internet Torsten Braun Universität Bern braun@iam.unibe.ch, cds.unibe.ch
  • 49. 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
  • 50. 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
  • 51. • 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
  • 52. 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 iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 5
  • 53. • 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 iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 6
  • 54. • 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 iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 7
  • 55. 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
  • 56. 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
  • 57. 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
  • 58. 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
  • 59. Architecture iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 12 Application Layer Control Layer Infrastructure Layer Business Applications SDN Control Software Network Services Network Device API API API
  • 60. 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
  • 61. Distributed Controller 14 partition and replicate state → scalability and reliability Network OS Controller Application Network OS Controller Application iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet
  • 62. 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
  • 63. 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
  • 64. 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. iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 17 OpenFlow Controller (secure) OpenFlow Channel Group/ Meter Table Flow Table Flow Table OpenFlow protocol (SSL/TLS) OpenFlow switch pipeline port
  • 65. Operation iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 18
  • 66. 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 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
  • 67. 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
  • 68. 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
  • 69. Packet Processing iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 22
  • 70. Packet Flow iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 23
  • 71. 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
  • 72. 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
  • 73. 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
  • 74. 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
  • 75. 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
  • 76. 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
  • 77. 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
  • 78. 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
  • 79. 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
  • 80. Network Function Virtualization (NFV) iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 33
  • 81. NFV Use Cases iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 34
  • 82. NFV Architecture iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 35 Operations/Business Support System Element Management System Virtual Network Function Management & Operation
  • 83. 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
  • 84. 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
  • 85. 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
  • 86. 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
  • 87. 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
  • 88. 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
  • 89. 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 iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 42
  • 90. 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
  • 91. IP Model iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 44 FIB FIB: Forwarding Information Base
  • 92. Messages iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 45 Interest Message Data Message
  • 93. 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
  • 94. Match in Content Store iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 47 FIB CS: Content Store FIB: Forwarding Information Base PIT: Pending Interest Table Name CS Name Data PIT
  • 95. Match in Forwarding Information Base iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 48 FIBCS Name PIT
  • 96. Match in Pending Interest Table iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 49 FIBCS Name PIT x
  • 97. 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
  • 98. 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
  • 99. 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
  • 100. 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
  • 101. 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
  • 102. 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 RId3RId4 RId5
  • 103. 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
  • 104. 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
  • 105. PSI Operation iCIS Summer Workshop, Coimbra, June 24, 2014 Torsten Braun: Future Internet 58
  • 106. 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

×