Politecnico di Milano Advanced Network Technologies Laboratory. 6LowPAN

Transcription

1 Politecnico di Milano Advanced Network Technologies Laboratory 6LowPAN

2 ACKs o Slide/Figures Sources n IPSO Alliance Webinar 6LowPAN for IP Smart Objects n 6LoWPAN: The Wireless Embedded Internet, Shelby & Bormann, ISBN: , (c) 2009 John Wiley & Sons Ltd

3 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

4 Architecture

5 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

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

7 Additional Features o Support for e.g. 64-bit and 16-bit addressing o Useful with low-power link layers such as IEEE , narrowband ISM and power-line communications o Network auto-configuration 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 )

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

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

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

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

12 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

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

14 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

15 Addressing Example

16 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 Address Compression) n 0: Stateless, 1: Context-based o SAM/DAM (Source/Destination Address Mode) 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

17 Traffic Class and Flow Label Compression

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

19 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

20 Multicast Addresses Compression

21 UDP Header Compression

22 UDP Header Compression o Assume common values for header fields and define compact forms n Ports within to (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

23 Link Local

24 Global Unicast

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

26 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

27 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

28 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

29 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

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

31 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

32 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

33 RPL Phylosophy o General Principle: Do Not Overact

34 ROLL RPL Ripple

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

36 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 not traverse any non-encrypted link

37 The Most Common Routing Metric o Node n Residual Energy (node) n CPU, Storage, WorkLoad, Battery/Mains o Link n Throughput (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

38 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

39 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 Advertisement 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

40 DODAG Construction

41 Step 1 and 2

42 Step 3

43 Final DODAG

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

45 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