networking Image: TRENDR You will need some form of global How to - - PowerPoint PPT Presentation

IoTSSC – End- to-end networking

Image: TRENDR

How to enable end- to-end connectivity?

• You will need some form of global

addressing (unique identifiers)

• A mechanism to transfer information

between different end points (routing protocol)

• While dealing with IoT specific constraints

(reduced computation capabilities, small messages, limited energy)

The need for IPv6

• You have seen that IPv4 has underpinned the growth of

the Internet and does solve the device addressing issue.

• However, IPv4 has just run out of addresses, especially

problematic in the context of trillions of IoT devices expected to be rolled out in the future.

• You may know that NAT permits sharing a single public IP

address among multiple hosts, by assigning those private addresses; however, NAT suffers though from serious problems, e.g. breaks up layered designs.

• IPv6 is the only long-term solution: move to larger

addresses – 128 bits (addressing 2128 UNIQUE interfaces).

IPv6 development

• Work on specification began in 1990. Currently specified by

RFC 2460 to RFC 2466

• Some of the major goals:

1. Support huge number of hosts 2. Reduce the size of routing tables 3. Simplify protocol → allow for faster packet processing 4. Improve security 5. Allow host roaming without address changing

• In general, IPv6 is not compatible with IPv4, but is

compatible with Internet control and transport protocols such as ICMP, OSPF, BGP, TCP, UDP, etc.

IPv6 header

• Header much simplified as compared to IPv6

(7 fields vs. 13) and has better support for options.

IPv6 header (fixed part)

Fixed part of the header: 40 Bytes. Version: 0110 (6) – Let routers know about packet type Traffic Clas lass: Used to distinguish different classes of services – useful for real-time traffic with strict req. Flo Flow Lab Label: : Marks groups of packets that should be treated in the same way, sort of connection oriented flavour Payload Le Length: Similar to ‘Total Length’ in IPv4, but header length omitted here. Ne Next Header: Points to the first optional extension header (if any). The last header uses this field to specify the transport layer protocol, e.g. TCP, UDP) Hop

• p Lim

Limit: Same functionality as TTL in IPv4.

IPv6 addressing

• New notation uses eight groups of hexadecimal digits

separated with colons.

• Example:

8000:0000:0000:0000:0123:4567:89AB:CDEF

IPv6 addressing

To reduce notation 3 optimisations are authorised: 1. Leading zeros within a group can be omitted 2. One or more groups of 16 zero bits can be replaced by a pair of colons

8000::123:4567:89AB:CDEF

3. IPv4 addresses can be written as a pair of colons followed by decimal representations

::192.31.20.46

Address types

Prefix fix Desc scrip iptio ion IPv4 equ equiv ivale lent ::/128 Unsp Unspeci cifie ied (used at boot up) 0.0.0.0 ::1/127 Loopb Loopback 127.0.0.1 ::ffff/96 Example: ::ffff:192.0.2.47 IPv Pv4 ma mapped (used to embed IPv4 addresses into IPv6) No equivalence fc00::/7 Example: fdf8:f53b:82e4::53 Uni nique Loca Local Add Address sses s (ULA (ULAs) s) Reserved for local use and are not

• public. (might not be unique)

Private addresses: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 fe80::/10 Example: fe80::200:5aee:feaa:20a2 Link-Local l Add Addresses Used on a single link or a non-routed common access, e.g. Eth. LAN. Not necessarily unique outside Link. 169.254.0.0/16 2000::/3 Gl Glob

• bal Uni

nicast No equivalent single block

Unicast addresses

48 bits 16b or fewer 64 bits

• The network prefix (the routing prefix combined with the subnet

id) is contained in the most significant 64 bits of the address.

• The size of the routing prefix may vary; a larger prefix size means a

smaller subnet id size.

• The bits of the subnet id field are available to the network

administrator to define subnets within the given network.

• The 64-bit interface identifier is either automatically generated

from the interface's MAC address using the modified EUI-64 format, obtained from a DHCPv6 server, automatically established randomly, or assigned manually.

Routing prefix Interface identifier subnet

Modified EUI-64

• MAC address:

00:0C:29:0C:47:D5

• Network prefix:

2001:db8:1:2::/64

• Resulting host address:

2001:db8:1:2:020C:29ff:fe0c:47d5

Extension headers

6 extensions defined for extra functionality

• Routing – Extended routing, e.g.IPv4 loose source route
• Fragmentation – Fragmentation and reassembly
• Authentication – Integrity and authentication, and

security

• Encapsulating Security Payload – Confidentiality
• Hop-by-Hop options – Special options that require hop-

by-hop processing

• Destination options – Optional information to be

examined by the destination node

IPv6 over IEEE 802.15.4 (6LoWPAN)

Challenges of E2E IoT Networking

Protocols such as IEEE 802.15.4 have limited packet sizes (standard size is 127 bytes)

• IPv6 fixed header: 40B; UDP header: 8B
• 802.15.4 header: 25B
• Security options may add: 21B

Only ly 33B B le left ft for data! Som

• me compression req

equired.

• IPv6 requires MTU=1280B

Pack cket fr fragmentation and rea eassembly is is req equired.

IPv6 over Low-power Wireless Personal Area Networks (6LoWPAN)

• 6LoWPAN (RFC 4944) introduces an adaptation layer to

enable the transport of IPv6 packets over 802.15.4 links

• Main functions:
• Fragmentation / reassembly
• Compression of IPv6 and UDP headers
• Why not use ZigBee (also over 802.15.4)? -> ZigBee

cannot easily communicate with other protocols (but more energy efficient)

6LoWPAN stack

*Texas Instruments: 6LoWPAN demystified

• CoAP (Constrained Application Protocol), MQTT (Message Queue

Telemetry Transport) - like HTTP but IoT focused (resource discovery, publish/subscribe, etc.)

• RPL (Routing Protocol for Low-Power and Lossy Networks)

Header compression

Key idea: omit fields if can be derived from the link layer / context Three scenarios: 1. Communication between devices on the same network – compress header to two bytes 2. Communication with a device outside local network, network prefix known – compress to 12 bytes 3. Communication with device on external network, device prefix not known – compress to 20 bytes (50%)

Header compression

All packets prefixed with a 1-byte a dispatch code (encapsulation header) First fragment’s header includes the datagram size (11 bits) and a datagram tag (16 bits).

Pattern Header type 00 XXXXXX NALP - Not A LoWPAN Packet 01 000001 IPv6 - Uncompressed IPv6 addresses 01 000010 LOWPAN_HC1 – Compressed IPv6 header 01 111111 ESC - Additional Dispatch octet follows … Others reserved + broadcast, fragmentation, mesh

Example

*Texas Instruments: 6LoWPAN demystified

Auto-configuration

• Devices assign themselves addresses without the need

for a DHCP server

• Generates link-local unicast address (FE80::IID)
• IID – based on IEEE 802.15.4 EUI-64 address, 16-bit

short address, or both.

• Router Solicitation (RS) used to discover network prefix

– this can be omitted in local communication

• Receive Router Advertisement (RA) – network prefix
• Send a neighbour solicitation (NS) message to check if

address in use – Duplicate Address Detection (DAD)

IPv6 Routing Protocol

• ver Low-power and

Lossy Networks (RPL)

Different node functionality

*Texas Instruments: 6LoWPAN demystified

Why not use existing protocols?

• Processing, memory, power constraints
• Single metric not always appropriate for all

scenarios (latency vs reliability vs energy)

• Multiple routing instances on the same physical

infrastructure make sense for different applications

• Potential point-to-multi-point traffic, many devices
• Directed Acyclic Graph (DAG) topology created to

avoid cycles

• RPL actually creates Destination Oriented DAGs

(DODAGs), i.e. with a single root

DAG vs DODAG

Roots

DO DODAG DAG

DODAG construction

• Nodes send link-local multicast DAG information
• bjects (DOI) – configuration + parent discovery
• Parents chosen to minimise the cost of path to the

DODAG root

• Nodes listen for DOIs and decide whether to join a

new DODAG, or to maintain one already existing

• Sometimes DOI requested via a DAG information

Solicitation (DIS)

Routing

• Each node has a rank relatively to the root (R=0)
• This can be number of hops (distance), expected

transmission count (ETX), other

• Upwards routes are towards nodes with a lower rank
• Downwards routes are towards node of increasing ranks
• Many-to-one communication: upwards
• One-to-many communication: downwards
• Point-to-point communication: upwards-downwards

Modes of operation (I)

St Stori ring: each nodes maintain routing table with

• mappings between all

destinations reachable via its sub-DODAG and

• Their respective next

hop node

A D C B E F G H Route: E -> B -> F

Modes of operation (II)

Non-stori ring:

• Only the root maintains

routing information;

• Exploits this by including

the information in the packet itself

A D C B E F G H Route: E -> B -> A -> B -> F

IoTSSC – The Cloud

What is the Cloud?

“A network of remote servers hosted on the Internet and used to store, manage, and process data in place

• f local servers or personal computers.”

(Oxford Dictionaries) Crucial component of IoT systems

• Device management and configuration
• Data aggregation, processing, storage, and analysis/

visualisation

• Service customisation and infrastructure sharing

Virtualisation

• Virtualisation is what enables clouds to run separate

workloads under strict resource partitioning

• Such separation allows to optimally utilise CPU and

memory, while providing security guarantees

• Two approaches:
• Virtual Machines – multiple instances of potentially

different OSes running on the same physical machine (Infrastructure as a Service – IaaS)

• Containers – different applications running on a

virtualised OS within partitions. Execution safe to the kernel even if apps may have security issues (Platform as a Service – PaaS)

Virtual Machines vs Containers

Advantages

• f the

Container Approach

FAST TO INSTANTIATE CAN BE DESTROYED AS NEEDED NO NEED FOR A HYPERVISOR OS LIBRARIES CAN BE SHARED EASY TO SCALE

Example (Simple web page - https://docs.docker.com/get-started/)

# Use an official Python runtime as a parent image FROM python:3.6 # Set the working directory to /app WORKDIR /app # Copy the current directory contents into the container at /app ADD . /app # Install any needed packages specified in requirements.txt RUN pip install -r requirements.txt # Make port 80 available to the world outside this container EXPOSE 80 # Define environment variable ENV NAME World # Run app.py when the container launches CMD ["python", "app.py"]

Example (continued)

app.py basically listens for connection on port 80 and returns an HTML page To run the app, simply call docker ru run -p 4000:80 docker-fi file le

• p maps port 80 of the container to port 4000 of the

localhost

Putting everything together

We talked about

• How to program embedded devices
• How to connect them to an Internet gateway wirelessly
• How to secure their communication
• How to instantiate apps in the cloud that could do

meaningful things with the data IoT devices may generate Remaining question: how to act ctually in integrate th the devices wit ith th the clo cloud?

Simplest way: HTTP

• Set up a lightweight service with HTTP transport and

REST (REpresentational State Transfer) API

• IoT device periodically collects measurements and

packages them into JSON format record={ “date”: “2018-04-04”, “time”: “09:30:00”, “temperature”: 20.1 }

• Sends these as HTTP POST requests to the server

Sending the post request

• You can do this e.g. in Python

import requests import json … url=“http://<uri_of_server_end_point” requests.post(url, data=json.dumps(measurements))

How to ensure only authorised devices send data?

Use OAuth (authorisation framework – RFC 6749/50)

www.websequencediagrams.com

MQ Telemetry Transport (MQTT)

• MQTT is a messaging protocol that allows users to

collect information from constrained IoT devices (or devices to communicate among each other – M2M) following a publish/subscribe paradigm

• Networking fabric assumed to be low bandwidth,

high latency

• Works at the application layer on top of TCP/IP
• Originally part of IBM’s “message queue” suite for

industrial applications

• Current architecture centred around a broker/server

MQTT

The MQTT broker

• Dispatches messages received from publishers

(different IoT devices) to the clients (subscriber)

• Different topics used as filters – possible to combine

multiple topics into topic levels

• Topics create ‘virtual channels’, which decouple the

publishers from the subscribers – scalability

• Three Quality of Service (QoS) levels defined – refer

to the guarantees of delivering a message

MQTT QoS

• Important feature – client can choose QoS level

based on network reliability

• Three levels defined:
• QoS 0 – at most once: best-effort delivery (message not

acknowledged by the recipient, nor stored and redelivered if subscriber unreachable)

• QoS 1 – at least once: guaranteed that the messages

delivered at least once to the receiver (though may be delivered more than once); message stored by sender until acknowledge by the receiver (PUBACK)

• QoS 2 – each message received exactly once (safest but

slowest)

Retained messages

• A publishing client has no guarantee that a message is

received by a subscriber.

• Only guarantees that message is delivered to the broker.
• Likewise, the subscriber has no guarantees about when

it will received the first message on a topic, as this depends strictly on publisher.

• Retain messages are like normal MQTT messages but

with the ‘retain’ flag set -> broker stores the last message with retain flag, and the QoS for that topic

• Clients receive these messages immediately after

subscribing.

Retained messages

• Subscriber receive a message even if not subscribed

to an exact topic but to the relevant topic level, e.g.

• Client A subscribes to /home/#
• Client B publishes a retained messages to

/home/bedroom1/temperature

• Client A receives the last temperature reading for that

room as soon as it subscribes

• To delete a retained message, the publisher sends a

new retained message with zero payload.

• On Linux, you can try mosquitto (broker) and

mosquitto-clients

Constrained Application Protocol (CoAP) – RFC 7252

Very similar to HTTP, uses URIs (coap://), but

• Works on top of UDP (faster), reliability handed off to

retransmissions implemented at Application layer

• Incorporates mechanism for discovering other devices
• Multicast support (send messages to groups of

recipients)

• Asynchronous messaging (no need to establish a

session)

• Caching (store requests and responses)
• Simple 4-byte packet header (low overhead)

CoAP features

• A node can act both as client and server – no need

for a central entity (unlike MQTT that needs a broker)

• Subscriptions – used when devices await updates,
• r to know if the state of a device has changed
• Firmware updates can be performed with Block

Mode transmissions – large files divided into smaller parts

• Additional security layer (DTLS) that can be

implemented between UDP and CoAP