Politecnico di Milano Advanced Network Technologies Laboratory. 6LowPAN

Politecnico di Milano Advanced Network Technologies Laboratory 6LowPAN

What is 6LoWPAN? o An Adaptation Layer to fit IPv6 over Low-Power wireless Area Networks o Defined by IETF standards n RFC 4919, 4944 n n draft-ietf-6lowpan-hc and -nd draft-ietf-roll-rpl IPv6

o Low-power RF + IPv6 = The Wireless Embedded Internet o 6LoWPAN makes this possible o The benefits of 6LoWPAN include: n n n n n n n n Benefits of 6LoWPAN Technology Open, long-lived, reliable standards Easy learning-curve Transparent Internet integration Network maintainability Global scalability Enables a standard socket API Minimal use of code and memory Direct end-to-end Internet integration o Multiple topology options

Evolution of Wireless Sensor Networks Price Scalability Cabling Proprietary radio + network ZigBee 6lowpan Internet Any vendor Z-Wave, prop. ISM etc. ZigBee and WHART 6lowpan ISA100 Cables Vendor lock-in Complex middleware Open development and portability 1980s 2000 2006 2008 -> Increased Productivity

Architecture

Architecture o LoWPANs are stub networks o Simple LoWPAN n Single Edge Router o Extended LoWPAN n Multiple Edge Routers with common backbone link o Ad-hoc LoWPAN n No route outside the LoWPAN o Internet Integration issues n Maximum transmission unit n Application protocols n IPv4 interconnectivity n Firewalls and NATs n Security IPv6-LoWPAN Router Stack

Adaptation Features o Efficient header compression n IPv6 base and extension headers, UDP header o Fragmentation n 1280 byte IPv6 MTU -> 127 byte 802.15.4 frames

Additional Features o Support for e.g. 64-bit and 16-bit 802.15.4 addressing o Useful with low-power link layers such as IEEE 802.15.4, narrowband ISM and power-line communications o Network autoconfiguration using neighbor discovery o Unicast, multicast and broadcast support n Multicast is compressed and mapped to broadcast o Support for IP routing (e.g. IETF RPL) o Support for use of link-layer mesh (e.g. 802.15.5)

Internet Protocol v6 o IPv6 (RFC 2460) = the next generation Internet Protocol n n n n Complete redesign of IP addressing Hierarchical 128-bit address with decoupled host identifier Stateless auto-configuration Simple routing and address management o Majority of traffic not yet IPv6 but... n n n n Most PC operating systems already have IPv6 Governments are starting to require IPv6 Most routers already have IPv6 support So the IPv6 transition is coming o 1400% annual growth in IPv6 traffic (2009)

IPv4 vs. IPv6 Addressing Image source: Indeterminant (Wikipeida) GFDL IPv4: 7x10-6 [addresses/m 2 ] IPv6: 666x10 21 [addresses/m 2 ]

IPv4 vs. IPv6 Header Image source: Bino1000, Mkim (Wikipeida) GFDL

The 6LoWPAN Format o 6LoWPAN is an adaptation header format n Enables the use of IPv6 over low-power wireless links n IPv6 header compression n UDP header compression o Format initially defined in RFC4944 o Updated by draft-ietf-6lowpan-hc (work in progress)

6LowPAN Header Compression at a Glance o o o Stateless compression Flow-independent compression Simple tricks on IPv6/UDP header n Common values for header fields => compact forms n Version is always 6 n Traffic Class and Flow Label are zero n Payload Length always derived from L2 header n Source and Destination Addresses can be elided (linklocal) and/or compressed depending on the context of the transmission

IPv6 Addressing o o o o 128-bit IPv6 address = 64-bit prefix + 64-bit Interface ID (IID) The 64-bit prefix is hierarchical n Identifies the network you are on and where it is globally The 64-bit IID identifies the network interface n Must be unique for that network n Typically is formed statelessly from the interface MAC address o Called Stateless Address Autoconfiguration (RFC2462) There are different kinds of IPv6 addresses n Loopback (0::1) and Unspecified (0::0) n Unicast with global (e.g. 2001::) or link-local (FE80::) scope n Multicast addresses (starts with FF::) n Anycast addresses (special-purpose unicast address)

6LoWPAN Addressing o o o IPv6 addresses are compressed in 6LoWPAN Prefix n Addresses within 6LoWPAN typically contain common prefix n Nodes typically communicate with one or few central devices n Establish state (contexts) for such prefixes only state maintenance n Support for up to 16 contexts 6LoWPAN compresses IPv6 addresses by Interface ID n Typically derived from L2 addr during autoconfiguration n Elide when Interface Identifier can be derived from L2 header

Addressing Example

The Header Compression header o TF (Traffic Class and Flow Label) n 0: Carried Inline (ECN+DSCP+Flow), 1: ECN+Flow, 2: ECN+DSCP, 3: All zero o NH (Next Header compression) n 0: Carried Inline, 1: Next Header is compressed o HLIM (Hop Limit = Inline, 1, 64, 255) n 0: Carried Inline, 1: 1, 2: 64, 3: 255 o CID (Context Identifier Extension) n 0: No 1-byte CID identifier, 1: 1-byte identifier follows o SAC/DAC (Source/Destination AddressCompression) n 0: Stateless, 1: Context-based o SAM/DAM (Source/Destination AddressMode) n 0: 16 bytes inline, 1: 8 bytes inline, 2: 2 bytes inline, 3: elided o M (Multicast Destination) n 0: Destination is not multicast, 1: Destination is multicast

Traffic Class and Flow Label Compression

Next Header and Hop limit compression o Next Header Field o Hop Limit Field

Addresses Compression o Source/Destination Address Compression modes o Stateless Mode (SAC/DAC=0) n Prefix is link-local (fe80::/10) o Context-Based (SAC/DAC=1) n Prefix taken from stored contexts (up to 16 contexts) n CID = 0, use ContextID = 0 n CID = 1, include 4-bit ContextID for source & destination

Multicast Addresses Compression

UDP Header Compression

UDP Header Compression o Assume common values for header fields and define compact forms n Ports within 61616 to 61632 (4 bits) n Length derived from IPv6 Length n Checksum may be elided if other integrity checks are in use (e.g. Ipsec) n n C (Checksum): 0: Inline, 1: Elide P (Ports): o o o o 0: Inline 1: Elide first 8 bits of Dest Port 2: Elide first 8 bits of Source Port 3: Elide first 12 bits of Source and Dest Ports

Link Local

Global Unicast

Fragmentation o IPv6 requires a minimum 2-PDU of 1280 bytes o 802.15.4 has a maximum payload of 127 bytes o IPv6 packets should be fragmented by 6LowPAN adaptation layer

Fragmentation Header o dgram_size: size of the fragment in bytes o dgram_tag: fragmentation ID (common to all fragments) o dgram_offset: fragmentation offset (word of 8 bytes). Elided in the 1 fragment

Fragmentation in Practice o The performance of large IPv6 packets fragmented over low-power wireless mesh networks is poor! n Lost fragments cause whole packet to be retransmitted n Low-bandwidth and delay of the wireless channel n 6LoWPAN application protocols should avoid fragmentation n Fragmentation handled at the application layer (COAP) n Compression should be used on existing IP application protocols when used over 6LoWPAN if possible

6LoWPAN Setup & Operation o Autoconfiguration is important in embedded networks o In order for a 6LoWPAN network to start functioning: n Link-layer connectivity between nodes (commissioning) n Network layer address configuration, discovery of neighbors, registrations (bootstrapping) n Routing algorithm sets up paths (route initialization) n Continuous maintenance

IPv6 Neighbor Discovery o IPv6 is the format - ND is the brains n One-hop routing protocol defined in RFC4861 o Defines the interface between neighbors o Finding Neighbors n Neighbor Solicitation / Neighbor Acknowledgement o Finding Routers n Router Solicitation / Router Advertisement o Address resolution using NS/NA o Detecting Duplicate Addresses using NS/NA o Neighbor Unreachability Detection using NS/NA o DHCPv6 may be used in conjunction with ND

IPv6 Neighbor Discovery

6LoWPAN Neighbor Discovery o o o Standard ND for IPv6 is not appropriate for 6LoWPAN: n Assumption of a single link for an IPv6 subnet prefix n Assumption that nodes are always on n Heavy use of multicast traffic (broadcast/flood in 6LoWPAN) n No efficient multihop support over e.g. 802.15.4 6LoWPAN Neighbor Discovery provides: n An appropriate link and subnet model for low-power wireless n Minimized node-initiated control traffic n Node Registration (NR) and Confirmation (NC) n Duplicate Address Detection (DAD) and recovery n Support for extended Edge Router infrastructures ND for 6LoWPAN has been specified in draft-ietf-6lowpan-nd (work in progress)

Prefix Dissemination o In normal IPv6 networks RAs are sent to a link based on the information (prefix etc.) configured for that router interface o In ND for 6LoWPAN RAs are also used to automatically disseminate router information across multiple hops

Node Registration o 6LoWPAN-ND Optimizes only the host-router interface n RFC4861 = signaling between all neighbors (distributed) o Nodes register with their neighboring routers n Exchange of NR/NC messages n Binding table of registered nodes kept by the router o Node registration exchange enables n Host/router unreachabilitydetection n Address resolution (a priori) n Duplicate address detection o Registrations are soft bindings n Periodically refreshed with a new NR message

NR/NC Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (NR)/(NC) Code Checksum +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TID Status P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Binding Lifetime Advertising Interval +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Owner Interface Identifier + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Owner Nonce +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Registration option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+

Typical 6LoWPAN-ND Exchange

What should be the Optimum Ideal Routing Protocol for WSNs o Shortest-path routes o Avoids overlap o Minimum energy consumption o Needs global topology information A B C D E F G

Types of Routing Protocols o Algorithm classes n n Distance-vector Links are associated with cost, used to find the shortest route. Each router along the path store local next-hop information about its route table. Link-state Each node acquires complete information about the network, typically by flooding. Each node calculated a shortest-path tree calculated to each destination. o Types of Signaling n n Proactive Routing information acquired before it is needed. Reactive Routing information discovered dynamically when needed. o Route metrics are an important factor

6LoWPAN Routing o Here we consider IP routing (at layer 3) o Routing in a LoWPAN n Single-interface routing n Flat address space (exact-match) n Stub network (no transit routing)

Protocols for 6LoWPAN o IP is agnostic to the routing protocol used n It forwards based on route table entries o Thus 6LoWPAN is routing protocol agnostic o Special consideration for routing over LoWPANs n Single interface routing, flat topology n Low-power and lossy wireless technologies n Specific data flows for embedded applications o MANET protocols useful in some ad-hoc cases n e.g. AODV, DYMO o New IETF working group formed n Routing over low-power and lossy networks (ROLL) n Developed specifically for embedded applications

IETF ROLL o Routing Over Low power and Lossy networks (ROLL) n Working group at the IETF o Standardizing a routing algorithm for embedded apps o Application specific requirements n Home automation n Commercial building automation n Industrial automation n Urban environments o Analyzed all existing protocols o Solution must work over IPv6 and 6LoWPAN o Protocol in-progress called RPL Ripple n Proactive distance-vector approach

Background o Constrained devices! (few Kbytes of RAM, dozens of Kbytes of Flash, 8/16-bit microcontroller) o Low-speed highly unstable lossy links (oscillation avoidance is a key) o Potentially very large scale (10-100sK nodes) o Unattended devices in harsh environments

RPL Phylosophy o General Principle: Do Not Overact

ROLL RPL Ripple

Requirements/Objectives o Unicast/Anycast/Multicast o Adaptive Routing n Different metrics o Constraint-Based Routing n Parallel Paths o Scalability o Goal: RPL builds up a Destination-Oriented Directed Acyclic Graph (DODAG) o What DODAG depends on the specific Objective Function (OF)

Metrics & Constraints o Metric: scalar to capture the link/path performance (reliability, interference, throughput, etc.) o Constraint: criteria to eliminate links from a DODAG o Routing OF combines metric and constraints n Es: find the path with the maximum reliability that does nottraverse any non-encryptedlink

The Most Common Routing Metric o Node n Residual Energy (node) n CPU, Storage, WorkLoad, Battery/Mains o Link n Troughput (local/global metric) n Latency (local/global metric) n Reliability (local/global metric) o Expected Transmission Count(ETX) o Link Quality Level (LQL) o Hop Count

o The average number of packet transmissions to successfully transmit a packet o Ex: The ETX A n Being the packet error probability from A to B and from B to A p and q, respectively, the ETX is: 1/[(1-p)(1-q)] n p and q can be estimated through periodic beaconing B

RPL Messages o DODAG Information Object (DIO) n Link Local Messages to Advertise/Build Up DODAG n Contains all the information to exchange metrics/set constraints o Destination Advertisment Object (DAO) n Used to propagate information on destination (prefixes) n Support to ptp and ptmp traffic o DODAG Information Solicitation (DIS) n Used to solicit DIOs

DODAG Construction

Step 1 and 2

Step 3

Final DODAG

Multiple Routing OF calls for Multiple DODAGs o The very same network may support different applications n Es: network with battery- and main-operated devices, high and low bandwidth links, and two applications (telemetry and alarming) n One time sensitive path for alarms (low latency, high reliability, no constraints on energy) n One non-time-sensitive path for telemetry energy optimized (do not traverse batteryoperated nodes)

o OF1: use the LQL as a global metric, minimize the number of low and fair quality links, avoid nonencrypted links o OF2: find the best path in terms of latency while avoiding poor quality links and battery-operated nodes

Taxonomy of Routing Protocols for Wireless Sensor Networks o DATA CENTRIC PROTOCOLS n Flooding, Gossiping, SPIN, Directed Diffusion, SAR (Sequential Assignment Routing), Rumor Routing, Constrained Anisotropic Diffused Routing, COUGAR, ACQUIRE, ZigBee, RPL o HIERARCHICAL PROTOCOLS n LEACH, PEGASIS, TEEN (Threshold Sensitive Energy Efficient Sensor Network Protocol) o LOCATION BASED (GEOGRAPHIC) PROTOCOLS n MECN, SMECN (Small Minimum Energy Com Netw), GAF (Geographic Adaptive Fidelity), GEAR, Distributed Topology/Geographic,