Download - IPv6 Header Compression for Global Addresses
07/24/2007 69th IETF Meeting - 6LoWPAN WG 1
IPv6 Header Compression for Global Addresses
Jonathan Hui
David Culler
draft-hui-6lowpan-hc1g-00 – “Stateless IPv6 Header Compression for Globally Routable Packets in 6LoWPAN Subnetworks”
07/24/2007 69th IETF Meeting - 6LoWPAN WG 2
“IPv6 Communication over IEEE 802.15.4” …
• 6LoWPAN supports IP communication using global (i.e., routable) IPv6 addresses– But it never compresses them!
• HC1 compression only applies to the special link local prefix.– Shared by all nodes in the PAN
• So if you use IP over 802.15.4 for what IP is typically used for (internetworking) you lose much of the virtue of 6LoWPAN.
=> Complement HC1 with HC1g stateless compression for a shared global prefix
07/24/2007 69th IETF Meeting - 6LoWPAN WG 3
Motivation• Why global addresses?
– End-to-end communication in networks with heterogeneous links• without a stateful (possibly application specific) translation gateway• data collection point may be multiple IP hops away
– End-to-end communication across different PANs– IP connects different subnetworks
• ZigBee does not
• LOWPAN_HC1 supports arbitrary addresses, but…– Only allows compression of the link-local (fe80::/64) prefix– Uncompressed addresses consume 32 bytes
• 1/4th the 802.15.4 MTU before link and 6LoWPAN headers!
• The Issue is compressing the origin / final IP addresses– Not the number of PAN hops between them
07/24/2007 69th IETF Meeting - 6LoWPAN WG 4
Why Global Addresses?• Monitoring and Control Applications
– Collector OR controller generally not a 802.15.4 device– Conventional device on conventional link
Collector/Controller
802.15.4 802.3
hartcomm.org
Transit Network
Sensor Patch
Patch Network
Data Service
Intranet/Internet
Client Data Browsingand Processing
Sensor Node
Gateway
Other information sources
Sensor Node
Transit Network
Sensor Patch
Patch Network
Data Service
Intranet/InternetIntranet/Internet
Client Data Browsingand ProcessingClient Data Browsingand Processing
Sensor Node
Gateway
Other information sources
Sensor Node
07/24/2007 69th IETF Meeting - 6LoWPAN WG 5
Why Global Addresses?• Monitoring and Control Applications
– Collector/controller often connected using other links
• Link-local requires a stateful translation gateway• What about multiple 802.15.4 egress points?
– Good for redundancy– But requires a translation gateway at each– How is state managed across them?
Collector/Controller
802.15.4
Translation Gateway
802.3
07/24/2007 69th IETF Meeting - 6LoWPAN WG 6
• Route directly to the data collector• Possibly through different egress points
Why Global Addresses?
Collector/Controller
802.15.4 802.3
07/24/2007 69th IETF Meeting - 6LoWPAN WG 7
• Multiple PANs– May be different in PAN ID, channel, MAC, network-
wide keys, etc.
Why Global Addresses?
802.15.4802.15.4
802.15.4
07/24/2007 69th IETF Meeting - 6LoWPAN WG 8
• Assigned IP addresses within a PAN– IP addresses are useful for naming– If assigned IP address is used to name source or
destination, no HC1 compression• Assigned prefix or assigned interface identifier
Why Global Addresses?
802.15.4
07/24/2007 69th IETF Meeting - 6LoWPAN WG 9
HC1g - In a Nutshell
• Shared context of the PAN includes its prefix• Define compression for prefix other than link-local
– PAN has a compressible global prefix (CGP)
• Compression of Interface IDs derived from short addrs• Similar to LOWPAN_HC1 encoding
– Compresses to 2 octets in best case– Allows arbitrary IPv6 addresses if needed– Same encoding octet– Uses lower-layer information when possible
• Support for compressed well-known multicast addresses– Neighbor discovery, DHCPv6– Uses 6LoWPAN short address encoding
07/24/2007 69th IETF Meeting - 6LoWPAN WG 10
HC1g Compliments HC1
• HC1 and HC1g identified by different dispatch values• HC1 is efficient for link-local communication• HC1g is efficient for off-link communication
– Or on-link using non-default prefix
802.15.4
6LoWPAN Mesh/Frag
LOWPAN_HC1 LOWPAN_HC1g
Upper Layer Protocols
Global CommunicationLink-Local Communication
07/24/2007 69th IETF Meeting - 6LoWPAN WG 11
LOWPAN_HC1g Addresses
• PAN has a compressible global prefix (CGP) associated with it– Prefix is elided whenever it matches the CGP
• Four HC1g address forms:– Full 128 bits for arbitrary IPv6 addresses
– 64 bits: prefix derived from CGP, IID carried inline
– 16 bits: prefix derived from CGP, 6LoWPAN encoded short inline
– 0 bits: prefix derived from CGP, IID derived from lower layers (e.g. 802.15.4 src/dest or 6LoWPAN orig/final)
Arbitrary Prefix Arbitrary IID
Elided Arbitrary IID
Elided SA
Elided
07/24/2007 69th IETF Meeting - 6LoWPAN WG 12
HC1g Encoding
• Source Compression
• Destination Compression
• Version, Traffic, Flow
• Next Header– in-line, UCP, ICMP, TCP
• L4 Compression– HC2 followsSC
0 1 2 3 4 5 6 7
DC V NH L4
07/24/2007 69th IETF Meeting - 6LoWPAN WG 13
LoWPAN HC1g 16-bit Addr
• 16-bit short address follows 6LoWPAN encoding
• Compression of IIDs derived from 802.15.4 short address– 802.15.4 short address when first bit is 0
– Upper 48-bits of IID is assumed to be zero
– U/L bit is also zero, indicating local scope
• Well-known multicast addresses– 16 bits starts with ’101’
– Allocates another range in 6LoWPAN short address encoding
• Neither are supported in LOWPAN_HC1
07/24/2007 69th IETF Meeting - 6LoWPAN WG 14
Multicast Address Compression• For commonly-used, well-known multicast addresses• Use 6LoWPAN short address encoding
– Prefix (8-bits): Compressed to 3-bit range
– Flags (4-bits): Assumed to be zero • permanent, not derived from prefix, doesn’t embed RP
– Scope (4-bits): Carried in-line
– Group ID (112-bits): Mapped to 9-bits• Only all-nodes and all-routers currently defined
• Can be used in LOWPAN_HC1g or Mesh Addressing
1 0 1 Scope Group ID0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1
FF Flags Scope Group ID
128 bits
07/24/2007 69th IETF Meeting - 6LoWPAN WG 15
Other Differences
• Changes made based on lessons learned from LOWPAN_HC1 implementations
• Possible lack of octet alignment– Can consume several hundred bytes of code
– Octet alignment broken in uncommon cases
– Saves at most one octet in best case (when used with HC_UDP)
– HC1g include 4-bit version field with Traffic Class and Flow Label
• HC_UDP not possible when using IP extension headers– HC2 bit changed to specify layer 4 compression
• Only UDP is currently valid, ICMP/TCP not yet defined
07/24/2007 69th IETF Meeting - 6LoWPAN WG 16
HC1g summary
• Compression for prefixes other than link-local– PAN has a compressible global prefix (CGP)
• Compression of Interface IDs derived from short addrs• Similar to LOWPAN_HC1 encoding, but for CGP
– Compresses to 2 octets in best case– Allows arbitrary IPv6 addresses if needed– Same encoding octet, same HC2– Uses lower-layer information when possible
• Support for compressed well-known multicast addresses– Neighbor discovery, DHCPv6– Uses 6LoWPAN short address encoding