draft-ietf-6lowpan-hc-02.txt   draft-ietf-6lowpan-hc-03.txt 
Network Working Group J. Hui, Ed. Network Working Group J. Hui, Ed.
Internet-Draft Arch Rock Corporation Internet-Draft Arch Rock Corporation
Updates: 4944 (if approved) P. Thubert Updates: 4944 (if approved) P. Thubert
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: May 5, 2009 November 1, 2008 Expires: May 21, 2009 November 17, 2008
Compression Format for IPv6 Datagrams in 6LoWPAN Networks Compression Format for IPv6 Datagrams in 6LoWPAN Networks
draft-ietf-6lowpan-hc-02 draft-ietf-6lowpan-hc-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2009. This Internet-Draft will expire on May 21, 2009.
Abstract Abstract
This document specifies an IPv6 header compression format for IPv6 This document specifies an IPv6 header compression format for IPv6
packet delivery in 6LoWPAN networks. The compression format relies packet delivery in 6LoWPAN networks. The compression format relies
on shared context to allow compression of arbitrary prefixes. This on shared context to allow compression of arbitrary prefixes. This
document specifies compression of multicast addresses and a framework document specifies compression of multicast addresses and a framework
for compressing next headers. This framework specifies UDP for compressing next headers. This framework specifies UDP
compression and is prepared for additional transports. compression and is prepared for additional transports.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 4 2. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 4
2.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5 2.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5
2.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Context Identifier Extension . . . . . . . . . . . . . 7 2.1.2. Context Identifier Extension . . . . . . . . . . . . . 7
2.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 8 2.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 8
2.2.1. Traffic Class and Flow Label Encoding . . . . . . . . 8 2.2.1. Traffic Class and Flow Label Compression . . . . . . . 8
2.2.2. IPv6 Address Encoding for Unicast Destinations . . . . 9 2.2.2. Stateless Multicast Addresses Compression . . . . . . 9
2.2.3. IPv6 Address Encoding for Multicast Destinations . . . 9 2.2.3. Stateful Multicast Addresses Compression . . . . . . . 10
3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 11 3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 11
3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 11 3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 11
3.2. UDP Header Compression . . . . . . . . . . . . . . . . . . 12 3.2. UDP Header Compression . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding
about 80 octets of actual MAC payload once security is turned on, on about 80 octets of actual MAC payload once security is turned on, on
a wireless link with a link throughput of 250 kbps or less. The a wireless link with a link throughput of 250 kbps or less. The
6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6
datagrams over such constrained links, taking into account limited datagrams over such constrained links, taking into account limited
bandwidth, memory, or energy resources that are expected in bandwidth, memory, or energy resources that are expected in
skipping to change at page 5, line 33 skipping to change at page 5, line 33
LOWPAN_IPHC can compress the IPv6 header down to 7 octets (1-octet LOWPAN_IPHC can compress the IPv6 header down to 7 octets (1-octet
dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source
Address, and 2-octet Destination Address). Address, and 2-octet Destination Address).
2.1. LOWPAN_IPHC Encoding Format 2.1. LOWPAN_IPHC Encoding Format
2.1.1. Base Format 2.1.1. Base Format
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | CM | SAM | DAM | | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: LOWPAN_IPHC Encoding Figure 2: LOWPAN_IPHC Encoding
TF: Traffic Class, Flow Label: TF: Traffic Class, Flow Label:
00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes)
01: ECN + 2-bit Pad + Flow Label (3 bytes) 01: ECN + 2-bit Pad + Flow Label (3 bytes)
10: Traffic Class (1 byte) 10: Traffic Class (1 byte)
11: Version, Traffic Class, and Flow Label are compressed. 11: Version, Traffic Class, and Flow Label are compressed.
NH: Next Header:
NH: Next Header:
0: Full 8 bits for Next Header are carried in-line. 0: Full 8 bits for Next Header are carried in-line.
1: The Next Header field is compressed and the next header is 1: The Next Header field is compressed and the next header is
compressed using LOWPAN_NHC, which is discussed in Section 3. compressed using LOWPAN_NHC, which is discussed in Section 3.
HLIM: Hop Limit: HLIM: Hop Limit:
00: The Hop Limit field is carried in-line. 00: The Hop Limit field is carried in-line.
01: The Hop Limit field is compressed and the the hop limit is 1. 01: The Hop Limit field is elided and the the hop limit is 1.
10: The Hop Limit field is compressed and the the hop limit is 10: The Hop Limit field is elided and the the hop limit is 64.
64. 11: The Hop Limit field is elided and the hop limit is 255.
11: The Hop Limit field is compressed and the hop limit is 255.
CM: Compression Mode: CID: Context Identifier Extension:
00: Stateful compression using a default context. In this case 0: No additional 8-bit Context Identifier Extension is used. If
the context for SAM and DAM is the default context. context-based compression is specified in either SC or DC, the
01: Stateful compression using an indexed context; In this case default context is used.
the context for SAM and DAM is indicated in additional context 1: An additional 8-bit Context Identifier Extension field
octets that extends the LOWPAN_IPHC field to disambiguate an immediately follows the DAM field.
elided prefix or address described by the SAM or DAM fields.
10: Stateless compression using a well-know (Link-Local) prefix; SAC: Source Address Compression
In this case, the context is the Link Local context and the 0: Source address compression uses stateless compression.
prefix is FE80::/64. This compression mode is used for link 1: Source address compression uses stateful, context-based
local to link local communication. compression.
11: Stateless compression using a well-know pattern; In this
case, the context for the source address is the Link Local SAM: Source Address Mode:
context and the prefix is FE80::/64. The compression for the If SAC=0:
destination address does not use a context but a well-known 00: 0 bits. The address is the unspecified address.
pattern used in multicast addresses. This compression mode is 01: 64 bits. The first 64-bits of the address are elided.
used for link local to link scoped multicast group The value of those bits is the link-local prefix padded with
communication. zeros. The remaining 64 bits are carried inline.
SAM & DAM: Source and Destination Address Mode: The values for the 10: 16 bits. The first 112 bits of the address are elided.
SAM field are generally are generically as follows: The value of those bits is the link-local prefix padded with
00: 128 bits: The whole Address is carried in-line. zeros. The remaining 16 bits are carried inline.
01: 64 bits: the first 64 bits of the Address are elided. The 11: 0 bits. The address is fully elided. The first 64 bits
value of those bits are taken from the context and padded with of the address are elided. The remaining 64 bits are
zeroes. The remaining 64 bits are carried inline. computed from the link-layer address as defined in
10: 16 bits: the first 112 bits of the Address are elided. The
value of those bits is taken from the context and padded with
zeroes. The remaining 16 bits are carried inline.
11: 0 bit. The Address is fully elided. The first 64 bits of
the Address are elided taken from the context. The remaining
64 bits are computed from the link layer address as defined in
[RFC4944]. [RFC4944].
This generic rule applies depending on the CM field and with If SAC=1:
exceptions as follows: 00: 128 bits. The full address is carried in-line.
CM field of 10 (well-known prefix): The value of 00 is reserved 01: 64 bits. The first 64-bits of the address are elided.
for SAM and DAM. The value of those bits is taken from the context and padded
with zeros. The remaining 64 bits are carried inline.
10: 16 bits. The first 112 bits of the address are elided.
The value of those bits is taken from the context and padded
with zeros. The remaining 16 bits are carried inline.
CM field of 11 (well-known pattern): The SAM value of 00 11: 0 bits. The address is fully elided. The first 64 bits
indicates that the Source Address is the unspecified address. are taken from the context. The remaining 64 bits are
The compression of the Destination Address relies on well-known computed from the link-layer address as defined in
patterns for multicast addresses as follows: [RFC4944].
00: 8 bits. Used to compress the most used permanently-
assigned multicast addresses. A prefix of FF02::/120 is M: Multicast Compression
elided. The remaining 8 bits are carried inline. 0: Destination address does not use multicast compression.
01: 24 bits. Used to compress Solicited-Node multicast 1: Destination address uses multicast compression.
addresses. A prefix of FF02::1:FF00:0/104 is elided. The
remaining 24 bits are carried inline. DAC: Destination Address Compression
10: 16 bits: The Compressed Multicast address fsmg where f is 0: Destination address compression uses stateless compression.
4-bit flags, s is 4-bit scope, and mg is the least 1: Destination address compression uses stateful, context-based
significant 8 bits of the multicast group identifier FFfs:: compression.
00mg. The 16 bits of fsmg are carried inline.
11: 24 bits: The Compressed Multicast address fsmgmg where f DAM: Destination Address Mode:
is 4-bit flags, s is 4-bit scope, and mgmg is the least If M=0: When DAC=0, any elided prefix bits are the link-local
significant 16 bits of the multicast group identifier FFfs:: prefix padded by zeros. When DAC=1, any elided prefix bits are
mgmg. The 24 bits of fsmgmg are carried inline. taken from the context and padded by zeros.
00: 128 bits. The full address is carried in-line.
01: 64 bits. The first 64-bits of the address are elided.
The remaining 64 bits are carried inline.
10: 16 bits. The first 112 bits of the address are elided.
The remaining 16 bits are carried inline.
11: 0 bits. The address is fully elided. The first 64 bits
of the address are elided. The remaining 64 bits are
computed from the link-layer address as defined in
[RFC4944].
If M=1 and DAC=0:
00: 48 bits. The address takes the form FFXX::00XX:XXXX:XXXX.
01: 32 bits. The address takes the form FFXX::00XX:XXXX.
10: 16 bits. The address takes the form FF0X::0XXX.
11: 8 bits. The address takes the form FF02::00XX.
If M=1 and DAC=1:
00: 128 bits. The full address is carried in-line.
01: 48 bits. The address takes the form FFXX::XX[plen]:
[prefix]:XXXX:XXXX. The values of plen and prefix are taken
from the specified context.
10: reserved
11: reserved
2.1.2. Context Identifier Extension 2.1.2. Context Identifier Extension
This specification expects that a concept of context is shared This specification expects that a concept of context is shared
between the node that compresses a packet and the node(s) that need between the node that compresses a packet and the node(s) that need
to expand it. The specification enables a node to use of up to 16 to expand it. The specification enables a node to use of up to 16
contexts. How the contexts are shared and maintained is out of contexts. How the contexts are shared and maintained is out of
scope. Actions in response to unknown and/or invalid contexts are scope. Actions in response to unknown and/or invalid contexts are
out of scope. out of scope.
If the CM field is set to '01' in the LOWPAN_HC encoding, then an If the CMF field is set to '01' in the LOWPAN_HC encoding, then an
additional octet extends the LOWPAN_HC encoding following the DAM additional octet extends the LOWPAN_HC encoding following the DAM
bits but before the IPv6 header fields that are carried in-line. The bits but before the IPv6 header fields that are carried in-line. The
additional octet identifies the prefix when the IPv6 source and/or additional octet identifies the prefix when the IPv6 source and/or
destination address is compressed. The context identifier is 4 bits destination address is compressed. The context identifier is 4 bits
for each address, supporting up to 16 contexts. The encoding is for each address, supporting up to 16 contexts. The encoding is
shown in Figure 3. shown in Figure 3.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| SAC | DAC | | SAC | DAC |
skipping to change at page 8, line 19 skipping to change at page 8, line 35
2.2. IPv6 Header Encoding 2.2. IPv6 Header Encoding
Fields carried in-line (in part or in whole) appear in the same order Fields carried in-line (in part or in whole) appear in the same order
as they do in the IPv6 header format [RFC2460]. The Version field is as they do in the IPv6 header format [RFC2460]. The Version field is
always elided. Unicast IPv6 addresses may be compressed to 64 or 16 always elided. Unicast IPv6 addresses may be compressed to 64 or 16
bits or completely elided. Multicast IPv6 addresses may be bits or completely elided. Multicast IPv6 addresses may be
compressed to 8, 16, or 24 bits. The IPv6 Payload Length field MUST compressed to 8, 16, or 24 bits. The IPv6 Payload Length field MUST
always be elided and inferred from lower layers using the 6LoWPAN always be elided and inferred from lower layers using the 6LoWPAN
Fragmentation header or the IEEE 802.15.4 header. Fragmentation header or the IEEE 802.15.4 header.
2.2.1. Traffic Class and Flow Label Encoding 2.2.1. Traffic Class and Flow Label Compression
The TF field in the LOWPAN_HC encoding indicate whether the Traffic The TF field in the LOWPAN_HC encoding indicate whether the Traffic
Class and Flow Label are carried in-line in the compressed IPv6 Class and Flow Label are carried in-line in the compressed IPv6
header. When Flow Label is included while the Traffic Class is header. When Flow Label is included while the Traffic Class is
compressed, an additional 4 bits are included to maintain byte- compressed, an additional 4 bits are included to maintain byte-
alignment. Two of the 4 bits contain the ECN bits from the Traffic alignment. Two of the 4 bits contain the ECN bits from the Traffic
Class field. Class field.
To ensure that the ECN bits appear in the same location for all To ensure that the ECN bits appear in the same location for all
encodings that include them, the Traffic Class field is rotated right encodings that include them, the Traffic Class field is rotated right
by 2 bits in the compressed IPv6 header. The encodings are shown by 2 bits in the compressed IPv6 header. The encodings are shown
below: below:
1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN| DSCP | rsv | Flow Label | |ECN| DSCP | rsv | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TF = 00 TF = 00: Traffic Class and Flow Label carried in-line.
1 2 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN|rsv| Flow Label | |ECN|rsv| Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TF = 01
TF = 01: Flow Label carried in-line.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|ECN| DSCP | |ECN| DSCP |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
TF = 10 TF = 10: Traffic Class carried in-line.
2.2.2. IPv6 Address Encoding for Unicast Destinations 2.2.2. Stateless Multicast Addresses Compression
IPv6 unicast addresses may be carried in-line in full or or LOWPAN_HC supports stateless compression of multicast address when M
compressed to 64, 16, or 0 bits. When compressed, the bits carried = 1 and SAC = 0. An IPv6 multicast address may be compressed down to
in-line represent the least significant bits of the suffix. The 48, 32, 16, or 8 bits using stateless compression. The format
value of the prefix depends on the value of the DDF field and supports compression of the Solicited-Node Multicast Address (FF02::
possibly the SAC field in the Context Identifier Extension. 1:FFXX:XXXX) as well as any IPv6 multicast address where the upper
bits of the multicast group identifier are zero. The compressed
forms only carry the least-significant bits of the multicast group
identifier. All compressed forms carry the multicast scope in-line
and all (except DAM=10) carry the multicast flags as well.
Destination is Global with No Context ID (DDF = 00): When the 1 2 3
source and/or destination addresses are compressed, the prefix is 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
identified by context 0. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination is Global with Context ID (DDF = 01): When the source | Flags | Scope | Group Identifier |
and/or destination addresses are compressed, the prefix is +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
identified by the SAC and DAC fields in the Context Identifier | Group Identifier |
Extension, respectively. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination is Link-Local Unicast (DDF = 10): When the source
and/or destination addresses are compressed, the prefix is the
link-local unicast prefix (FE80::/10).
When an address is completely elided, the lower bits are inferred DAM = 00. 48-bit Compressed Multicast Address (FFfs::00gg:gggg:gggg)
from lower layers (either from the 6LoWPAN Mesh Addressing header or
from the IEEE 802.15.4 header). Specifically, if the lower-layer
header contains an extended 802.15.4 address, then a 64-bit suffix is
derived from the lower-layer header. If the lower-layer header
contains short 802.15.4 address, then a 16-bit suffix is derived from
the lower-layer header.
2.2.3. IPv6 Address Encoding for Multicast Destinations 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 source addresses with link-local scope may be compressed when DAM = 01. 32-bit Compressed Multicast Address (FFfs:00gg:gggg).
the destination address is a multicast address. The IPv6 source
address may be compressed to 64, 16, or 0 bits. The encoding also
supports the compression of the unspecified address (::).
SAM = 00: Source Address is the unspecified address and all 128 bits 1
are elided. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
SAM = 01: 64-bit prefix is elided and is the link-local (FE80::/10). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
64-bit Suffix is carried in-line. | Scope | Group Identifier |
SAM = 10: 112-bit prefix is elided and is the link-local +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(FE80::/10). 16-bit Suffix is carried in-line.
SAM = 11: All 128 bits of Source Address are elided. The prefix is
the link-local prefix (FE80::/10). The suffix is derived from
lower-layer headers.
IPv6 multicast addresses may be comrpessed down to 24, 16, or 8 bits. DAM = 10. 16-bit Compressed Multicast Address (FF0s::0ggg).
The format supports compression of the Solicited-Node Multicast
Address (FF02::1:FFXX:XXXX) as well as any IPv6 multicast address
where the upper 104 bits of the multicast group identifier are zero
(FFXX::XXXX). The encoding format also compressed link-local
multicast addresses of the form (FF02::00XX) down to a single byte.
The compressed form only carries least-significant bits of the
multicast group identifier.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Group ID | | Group ID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
DAM = 00. 8-bit Compressed Multicast Address (FF02::00mg) DAM = 11. 8-bit Compressed Multicast Address (FF02::gg).
1 2 2.2.3. Stateful Multicast Addresses Compression
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last 24 bits of Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DAM = 01. Compressed Solicited-Node Address (FF02::1:FFXX:XXXX). LOWPAN_HC supports stateful compression of multicast addresses when M
= 1 and SAC = 1. This document currently defines SAM = 01: context-
based compression of Unicast-Prefix-based IPv6 Multicast Addresses
[RFC3306][RFC3956]. In particular, the Prefix Length and Network
Prefix can be taken from a context. As a result, LOWPAN_HC can
compress a Unicast-Prefix-based IPv6 Multicast Address down to 6
octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit RIID, and
32-bit Group Identifier in-line.
1 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Group ID | | Flags | Scope | Reserved | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DAM = 10. 16-bit Compressed Multicast Address (FFfs::00mg).
1 2 DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Last 16 bits of Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DAM = 11. 24-bit Compressed Multicast Address (FFfs::mgmg). Note that the Reserved field MUST carry the reserved bits from the
multicast address format as described in [RFC3306]. When a
Rendezvous Point is encoded in the multicast address as described in
[RFC3956], the Reserved field carries the RIID bits in-line.
3. IPv6 Next Header Compression 3. IPv6 Next Header Compression
LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set
to 1. It also indicates the use of 6LoWPAN next header compression, to 1. It also indicates the use of 6LoWPAN next header compression,
LOWPAN_NHC. The value of IPv6 Next Header is recovered from the LOWPAN_NHC. The value of IPv6 Next Header is recovered from the
first bits in the LOWPAN_NHC encoding. The following bits are first bits in the LOWPAN_NHC encoding. The following bits are
specific to the IPv6 Next Header value. Figure 4 shows the structure specific to the IPv6 Next Header value. Figure 4 shows the structure
of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC. of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC.
skipping to change at page 13, line 27 skipping to change at page 13, line 29
context. How the shared context is assigned and managed is beyond context. How the shared context is assigned and managed is beyond
the scope of this document. the scope of this document.
6. Acknowledgements 6. Acknowledgements
Thanks to Julien Abeille, Carsten Bormann, Christos Polyzois, and Jay Thanks to Julien Abeille, Carsten Bormann, Christos Polyzois, and Jay
Werb for useful feedback and discussion. Werb for useful feedback and discussion.
7. Changes 7. Changes
Draft 03:
- Decoupled meaning of SAM bits from the destination address.
- Have separate bit to indicate multicast address compression.
- More extensive support for multicast address compression,
including Unicast-Prefix-based Multicast Addresses.
Draft 02: Draft 02:
- Updated wording with compression mode to clarify that a - Updated wording with compression mode to clarify that a
compression mode does not enforce what kind of destination address compression mode does not enforce what kind of destination address
is being used. Specifically changed Destination Dependent Field is being used. Specifically changed Destination Dependent Field
to Compression Mode. to Compression Mode.
- Specify that the configuration and management of contexts is out - Specify that the configuration and management of contexts is out
of scope of this document. of scope of this document.
Draft 01: Draft 01:
- HC back to 1 byte by default by stealing a few bits from the - HC back to 1 byte by default by stealing a few bits from the
dispatch field. dispatch field.
- Added better support for multicast address compression. - Added better support for multicast address compression.
- Fixed alignment for UDP port compression. - Fixed alignment for UDP port compression.
- Better support for Traffic Class and Flow Label compression. - Better support for Traffic Class and Flow Label compression.
- Pascal joined as an author. - Pascal joined as an author.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 14, line 25 skipping to change at page 14, line 39
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
8.2. Informative References 8.2. Informative References
[IEEE 802.15.4] [IEEE 802.15.4]
IEEE Computer Society, "IEEE Std. 802.15.4-2006", IEEE Computer Society, "IEEE Std. 802.15.4-2006",
October 2006. October 2006.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
Authors' Addresses Authors' Addresses
Jonathan W. Hui (editor) Jonathan W. Hui (editor)
Arch Rock Corporation Arch Rock Corporation
501 2nd St. Ste. 410 501 2nd St. Ste. 410
San Francisco, California 94107 San Francisco, California 94107
 End of changes. 37 change blocks. 
135 lines changed or deleted 158 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/