draft-ietf-6lowpan-hc-01.txt   draft-ietf-6lowpan-hc-02.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: April 12, 2009 October 9, 2008 Expires: May 5, 2009 November 1, 2008
Compression Format for IPv6 Datagrams in 6LoWPAN Networks Compression Format for IPv6 Datagrams in 6LoWPAN Networks
draft-ietf-6lowpan-hc-01 draft-ietf-6lowpan-hc-02
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 April 12, 2009. This Internet-Draft will expire on May 5, 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.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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 Encoding . . . . . . . . 8
2.2.2. IPv6 Address Encoding for Unicast Destinations . . . . 9 2.2.2. IPv6 Address Encoding for Unicast Destinations . . . . 9
2.2.3. IPv6 Address Encoding for Multicast Destinations . . . 9 2.2.3. IPv6 Address Encoding for Multicast Destinations . . . 9
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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15 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
applications such as wireless Sensor Networks. [RFC4944] defines a applications such as wireless Sensor Networks. [RFC4944] defines a
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 | DDF | SAM | DAM | | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | CM | SAM | 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 compressed 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 compressed and the the hop limit is
64. 64.
11: The Hop Limit field is compressed and the hop limit is 255. 11: The Hop Limit field is compressed and the hop limit is 255.
DDF: Destination Dependant Field: CM: Compression Mode:
00: Destination and Source are Global or Unique Local Addresses 00: Stateful compression using a default context. In this case
01: Destination and Source are Global or Unique Local Addresses the context for SAM and DAM is the default context.
and one additional context octet extends the LOWPAN_IPHC field 01: Stateful compression using an indexed context; In this case
to disambiguate an elided prefix or address described by the the context for SAM and DAM is indicated in additional context
SAM or DAM fields. octets that extends the LOWPAN_IPHC field to disambiguate an
10: Destination and Source are Link Local Addresses elided prefix or address described by the SAM or DAM fields.
11: Destination is a Multicast Address, Source is either the 10: Stateless compression using a well-know (Link-Local) prefix;
unspecified address or a Link Local Address In this case, the context is the Link Local context and the
SAM: Source Address Mode: prefix is FE80::/64. This compression mode is used for link
When the Destination is a Global or Unique Local Addresses: local to link local communication.
00: 128 bits: The whole Source Address is carried in-line. 11: Stateless compression using a well-know pattern; In this
01: 64 bits: the prefix of Source Address is elided. case, the context for the source address is the Link Local
10: 16 bits: the first 112 bits of the Source Address are context and the prefix is FE80::/64. The compression for the
elided. destination address does not use a context but a well-known
11: 0 bit: The Source Address is fully elided. pattern used in multicast addresses. This compression mode is
When the Destination is a Link Local Addresses: used for link local to link scoped multicast group
00: Reserved, should not be used communication.
01: 64 bits: the prefix of Source Address is elided. SAM & DAM: Source and Destination Address Mode: The values for the
10: 16 bits: the first 112 bits of the Source Address are SAM field are generally are generically as follows:
elided. 00: 128 bits: The whole Address is carried in-line.
11: 0 bit: The Source Address is fully elided. 01: 64 bits: the first 64 bits of the Address are elided. The
When the Destination is a Multicast Addresses: For the value of value of those bits are taken from the context and padded with
SAM of 00, the Source Address is the unspecified address. For zeroes. The remaining 64 bits are carried inline.
all values of SAM except 00, the Source Address is the Link 10: 16 bits: the first 112 bits of the Address are elided. The
Local Address of the node. value of those bits is taken from the context and padded with
00: 0 bit: The Source Address is the unspecified address and zeroes. The remaining 16 bits are carried inline.
it is fully elided. 11: 0 bit. The Address is fully elided. The first 64 bits of
01: 64 bits: the prefix of Source Address is elided. the Address are elided taken from the context. The remaining
10: 16 bits: the first 112 bits of the Source Address are 64 bits are computed from the link layer address as defined in
elided. [RFC4944].
11: 0 bit: The Source Address is fully elided. This generic rule applies depending on the CM field and with
DAM: Destination Address Mode: exceptions as follows:
When the Destination is a Global or Unique Local Addresses: CM field of 10 (well-known prefix): The value of 00 is reserved
00: 128 bits: The whole Destination Address is carried in- for SAM and DAM.
line.
01: 64 bits: the prefix of Destination Address is elided. CM field of 11 (well-known pattern): The SAM value of 00
10: 16 bits: the first 112 bits of the Destination Address are indicates that the Source Address is the unspecified address.
elided. The compression of the Destination Address relies on well-known
11: 0 bit: The Destination Address is fully elided. patterns for multicast addresses as follows:
When the Destination is a Link Local Addresses:
00: Reserved, should not be used
01: 64 bits: the prefix of Source Address is elided.
10: 16 bits: the first 112 bits of the Source Address are
elided.
11: 0 bit: The Source Address is fully elided.
When the Destination is a Multicast Addresses:
00: 8 bits. Used to compress the most used permanently- 00: 8 bits. Used to compress the most used permanently-
assigned multicast addresses. A prefix of FF02::/120 is assigned multicast addresses. A prefix of FF02::/120 is
elided. elided. The remaining 8 bits are carried inline.
01: 24 bits. Used to compress Solicited-Node multicast 01: 24 bits. Used to compress Solicited-Node multicast
addresses. A prefix of FF02:0:0:0:0:1:FF00/104 is elided. addresses. A prefix of FF02::1:FF00:0/104 is elided. The
remaining 24 bits are carried inline.
10: 16 bits: The Compressed Multicast address fsmg where f is 10: 16 bits: The Compressed Multicast address fsmg where f is
4-bit flags, s is 4-bit scope, and mg is the least 4-bit flags, s is 4-bit scope, and mg is the least
significant 8 bits of the multicast group identifier FFfs:: significant 8 bits of the multicast group identifier FFfs::
00mg. 00mg. The 16 bits of fsmg are carried inline.
11: 24 bits: The Compressed Multicast address fsmgmg where f 11: 24 bits: The Compressed Multicast address fsmgmg where f
is 4-bit flags, s is 4-bit scope, and mgmg is the least is 4-bit flags, s is 4-bit scope, and mgmg is the least
significant 16 bits of the multicast group identifier FFfs:: significant 16 bits of the multicast group identifier FFfs::
mgmg. mgmg. The 24 bits of fsmgmg are carried inline.
2.1.2. Context Identifier Extension 2.1.2. Context Identifier Extension
If the DDF field is set to '01' in the LOWPAN_HC encoding, then an This specification expects that a concept of context is shared
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
contexts. How the contexts are shared and maintained is out of
scope. Actions in response to unknown and/or invalid contexts are
out of scope.
If the CM 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 13, line 25 skipping to change at page 13, line 25
albeit in a less efficient form. It recognizes that a IEEE 802.15.4 albeit in a less efficient form. It recognizes that a IEEE 802.15.4
PAN may have associated with it a number of prefixes through shared PAN may have associated with it a number of prefixes through shared
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. References 7. Changes
7.1. Normative References Draft 02:
- Updated wording with compression mode to clarify that a
compression mode does not enforce what kind of destination address
is being used. Specifically changed Destination Dependent Field
to Compression Mode.
- Specify that the configuration and management of contexts is out
of scope of this document.
Draft 01:
- HC back to 1 byte by default by stealing a few bits from the
dispatch field.
- Added better support for multicast address compression.
- Fixed alignment for UDP port compression.
- Better support for Traffic Class and Flow Label compression.
- Pascal joined as an author.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005. March 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[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.
7.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.
[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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
 End of changes. 16 change blocks. 
63 lines changed or deleted 82 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/