03/11/200871st IETF Meeting - 6LoWPAN WG1 Compression Format for IPv6 Datagrams in 6LoWPAN Networks Jonathan Hui 6LoWPAN WG Meeting 71 st IETF Meeting

03/11/2008 71st IETF Meeting - 6LoWPAN WG 1

Compression Format for IPv6 Datagrams in 6LoWPAN Networks

Jonathan Hui

6LoWPAN WG Meeting71st IETF MeetingPhiladelphia, PA


RFC 4944 – IPv6 Header Compression

• Most effective when communicating with link-local addresses– Prefix: must be carried in-line when not link-local

• Route-over, ROLL

• Communicating with devices outside PAN

– Suffix: must be 64 bits when carried in-line• No provision to shorten it even when IID is derived from short

802.15.4 address.

– Multicast: must carry all 128 bits in-line• Even for commonly used multicast addresses (e.g. link-local all

nodes, IPv6 ND, etc.)

– Hop-limit always carried in-line

SA DA NHTF

0 1 2 3 4 5 6 7

uncompressed fields…HC2


RFC 4944 – Next Header Compression

• Defined for UDP header– No way to elide Checksum

• End-to-end integrity checks may be provided by other end-to-end mechanisms (e.g. security).

– No support for future compression of arbitrary next headers

• UDP, TCP, or ICMPv6 only


Proposed 6LoWPAN HC

• Generalize LOWPAN_HC1/HC2– Broader range of communication paradigms

• Mesh-under, route-over, communication with external devices, multicast

– Framework for compression of arbitrary next headers• UDP compression initially defined within this framework

– IPv6 Hop Limit and UDP Checksum compression– Carry forward design concepts

• Minimize state• Rely on shared context


LOWPAN_IPHCIPv6 Header Compression

• VTF: Version, Traffic Class, Flow Label• NH: Next Hop• HLIM: Hop Limit• SA: Source Address• DA: Destination Address• rsv: reserved• Payload Length always elided

VTF NH HLIM SA DA

0 1 2 3 4 5 6 7

uncompressed fields…


LOWPAN_IPHCAddress Compression

Full 128-bit Address In-Line

64-bit Suffix In-LineCP Implicit

SACP Implicit 0’s

CP Implicit From Lower Layers

• Common Prefix (CP)– Implicit when prefix is elided– Link-local (LL) or Common Routable Prefix (CRP)

• Identified by different 6LoWPAN Dispatch values

• SA derived from IEEE 802.15.4 Short Address• Elided suffix derived from lower-layers

00: 128 bits

01: 64 bits

10: 16 bits

11: 0 bits


LOWPAN_IPHCObtaining the Common Routable Prefix

• Assumption– 6LoWPAN network operate under a single administrative domain

• Single-homed– CRP is trivial (the only prefix assigned to the PAN).– Renumbering inconsistencies caught with pseudo-header

checksum

• Multi-homed– Need to specify a protocol and think through the operational

details– Can we go without for now?


LOWPAN_IPHCIID Derived from 802.15.4 Short Addresses

• RFC 4944– Includes PAN ID and 0xFFFE– Is there a need to assign the same prefix to >1 PAN?

• Instead, prefix Short Address with zeros– u/l-bit is zero, indicating local scope– Could also be some fixed bit-pattern, other than 0’s.

SA0’s


LOWPAN_IPHCHop Limit Compression

• 1 bit to indicate compression• 1 bit to indicate 63 (egress) or 1 (ingress)

• Most useful for mesh-under– All nodes connected via a single IP hop

• Not as useful for route-over– Forwarding nodes have to expand anyway


128 bits

LOWPAN_IPHCMulticast Address Compression

1 0 0 Scope Group ID0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

FF Flags Scope Group ID

• For commonly-used, well-known multicast addresses– Divide 16-bit compressed address into ranges

• Unicast: 0xxxxxxxxxxxxxxx• Multicast: 100xxxxxxxxxxxxx

• 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

– Currently defined: All Nodes (1) and All Routers (2)


LOWPAN_NHCNext Header Compression

ID SP DP C rsv

0 1 2 3 4 5 6 7

uncompressed fieds…

• IPHC NH indicates next header compression– IPv6 Next Header elided, derived from first bits in NHC– Encoding gives shorter bit-patterns to frequently used next headers

• ID: 0 for UDP, 1 for other• SP: Source Port• DP: Destination Port• C: Checksum• Length always elided

• Checksum MUST NOT be elided when no other end-to-end integrity cover the pseudo-header, UDP header, and UDP payload


Unicast Examples

• Link-Local, Mesh-Under (9 bytes)

• Link-Local, Route-Over (4 bytes)

• Routable, Mesh-Under (9 bytes)

• Routable Addresses, Route-Over (9 bytes)

Disp. IPHC NHC Ports


6LoWPAN Mesh Header

Disp. IPHC NHC Ports6LoWPAN Mesh Header

Disp. IPHC HLIM Src Addr Dst Addr NHC Ports15.4

15.4

15.4

15.4

5 1 1 1 1

1 1 1 1

5 1 1 1 1

1 11 1 1 2 2


Multicast Examples

• Link-Local, Mesh-Under (11 bytes)

• Link-Local, Route-Over (6 bytes)

• Routable, Mesh-Under (11 bytes)

• Routable Addresses, Route-Over (9 bytes)



6LoWPAN Mesh Header

Disp. IPHC HLIM Src Addr Dst Addr NHC Ports15.4

15.4

15.4 Disp. Bcast

Dst Addr

Disp. IPHC NHC Ports6LoWPAN Mesh Header15.4 Disp. Bcast

1 1 1 11 15

1 1 1 11 15

1 11 1 1 2 2


6LoWPAN HC Summary

• Generalize LOWPAN_HC1/HC2– Broader range of communication paradigms

• Mesh-under, route-over, communication with external devices, multicast

– Framework for compression of arbitrary next headers• UDP compression initially defined within this framework

– IPv6 Hop Limit and UDP Checksum compression– Carry forward design concepts

• Minimize state• Rely on shared context


Discussion

• Should 6lowpan-hc become a WG doc?


Combining IPHC and NHC(From Discussion with Pascal Thubert)

• Another dispatch for combining LOWPAN_IPHC/NHC?– Fully elided Source and Destination addresses and Hop Limit– Next header compression

• Pro: Save an additional octet• Con: Additional code overhead

VTF rsv

0 1 2 3 4 56 7

uncompressed fields…SP DP CHLIM

5

0

Documents

03/11/200871st IETF Meeting - 6LoWPAN WG1 Compression Format for IPv6 Datagrams in 6LoWPAN Networks Jonathan Hui 6LoWPAN WG Meeting 71 st IETF Meeting