Internet DRAFT - draft-thubert-6lo-inner-compression
draft-thubert-6lo-inner-compression
6lo P. Thubert, Ed.
Internet-Draft Cisco
Updates: 6282 (if approved) X. Vilajosana
Intended status: Standards Track Universitat Oberta de Catalunya
Expires: August 13, 2016 S. Duquennoy
Inria
February 10, 2016
6LoWPAN Inner Compression
draft-thubert-6lo-inner-compression-00
Abstract
This specification modifies 6LoWPAN stateless address compression to
enable the compression by 6LOWPAN_IPHC of non Link-Local addresses in
an IP header when a reference address can be found in an
encapsulation. .
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 13, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Thubert, et al. Expires August 13, 2016 [Page 1]
Internet-Draft 6LoWPAN Inner Compression February 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Updating RFC 6282 . . . . . . . . . . . . . . . . . . . . . . 3
4. Compression References . . . . . . . . . . . . . . . . . . . 3
4.1. For Source IP From Encapsulating IP Header . . . . . . . 4
4.2. For Destination IP From Encapsulating IP Header . . . . . 4
4.3. Preceding 6LoRH Header . . . . . . . . . . . . . . . . . 4
5. Stateless Compression of the Source Address . . . . . . . . . 5
6. Stateless Compression of the Destination Address . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, a very constrained resource in most cases.
The other constraints, such as the memory capacity and the duty
cycling of the LLN devices, derive from that primary concern. Energy
is often available from primary batteries that are expected to last
for years, or is scavenged from the environment in very limited
quantities. Any protocol that is intended for use in LLNs must be
designed with the primary concern of saving energy as a strict
requirement.
Controlling the amount of data transmission is one possible venue to
save energy. In a number of LLN standards, the frame size is limited
to much smaller values than the IPv6 maximum transmission unit (MTU)
of 1280 bytes. In particular, an LLN that relies on the classical
Physical Layer (PHY) of IEEE 802.15.4 [IEEE802154] is limited to 127
bytes per frame. The need to compress IPv6 packets over IEEE
802.15.4 led to the 6LoWPAN Header Compression [RFC6282] work
(6LoWPAN-HC).
6LoWPAN-HC is designed to support more than one IPv6 address per node
and per Interface Identifier (IID), an IID being typically derived
from a MAC address to optimize the compression. The stateless
address compression modes (SAC/DAC=0) enable the compression of Link
Local Addresses only. The suffix is found either in-line or in the
Thubert, et al. Expires August 13, 2016 [Page 2]
Internet-Draft 6LoWPAN Inner Compression February 2016
MAC header or an encapsulating IP header. The other addresses,
Global and Unique-Local Addresses, can be only compressed with
stateful address compression modes (SAC/DAC=1), whereby the prefix is
found in a context.
In the case of an IP-in-IP encapsulation in a LLN, either or both the
source or the destination address in the inner header is usually
derived from the same prefix as the encapsulating header and could be
compressed without a context. This specification updates [RFC6282]
stateless address compression to use the prefixes found in
encapsulating headers as compression reference as opposed to the link
local prefix.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
The Terminology used in this document is consistent with and
incorporates that described in `Terminology in Low power And Lossy
Networks' [RFC7102] and [RFC7228].
3. Updating RFC 6282
This draft updates the LOWPAN-IPHC compression specified in 6LoWPAN-
HC [RFC6282] in the cases where SAC=0 and where M=0 and DAC=0.
The change is that the prefix that is used as compression reference
is not necessarily derived from the link local prefix but may be
obtained from a preceding header.
If no prefix is located in a preceding header then the stateless
compression based on the link local prefix and specified in [RFC6282]
still applies.
Locating a prefix for the compression of the source address (SAC=0)
is discussed in Section 4.1 and Section 4.3. Locating a prefix for
the compression of the destination address (M=0 and DAC=0) is
discussed in Section 4.2 and Section 4.3.
4. Compression References
The native origin for a compression reference is in an IP-in-IP
encapsulating header. This is discussed in Section 4.1 and
Section 4.2. Other headers such as the 6LoWPAN Routing Header
Thubert, et al. Expires August 13, 2016 [Page 3]
Internet-Draft 6LoWPAN Inner Compression February 2016
[I-D.ietf-6lo-routing-dispatch] (6LoRH) can be also serve as
reference; that particular case is discussed in Section 4.3.
4.1. For Source IP From Encapsulating IP Header
If the IP header that is compressed with LoWPAN_IPHC is encapsulated
in another IP header, the compression reference is the source of that
encapsulating header, that is the address of the node that performed
the encapsulation, whether that encapsulating header was itself
encapsulated again or not.
4.2. For Destination IP From Encapsulating IP Header
If the IP header that is compressed with LoWPAN_IPHC is encapsulated
in another IP header, the compression reference is the address of the
destination of the encapsulating IP packet, that is the node that
eventually performs the decapsulation of the IP header.
If a routing header is present in the encapsulating IP header chain,
this is the last address in the last routing header at the time the
encapsulation is generated. In the uncompressed form of a Routing
Header type 3 [RFC6554], it is swapped with the address of the
destination at the time the packet reaches it, and thus found in the
IP header as opposed to the routing header.
4.3. Preceding 6LoRH Header
The 6LoWPAN Routing Header [I-D.ietf-6lo-routing-dispatch]
specification documents a compression scheme for the RPL artifacts in
data packet. The compressed format places the artifacts in 6LoRH
Headers that are located before the LOWPAN_IPHC, even when there is
not IP-in-IP encapsulation.
If there is no IP-in-IP encapsulation but the IP header that is
compressed with LoWPAN_IPHC is preceded in the compressed form by an
RH3-6LoRH header, then the last address in the last RH3-6LoRH header
is the compression reference for the destination address.
If there is an IP-in-IP encapsulation compressed with IP-in-IP-6LoRH,
then the address of the destination of the encapsulating IP packet is
encoded in a RH3-6LoRH as well, so the last address in the last
RH3-6LoRH header is also the compression reference for the
destination address.
If there is no IP encapsulation but the IP header that is compressed
with LoWPAN_IPHC is preceded in the compressed form by an RPI-6LoRH
header that identifies a RPL DODAG [RFC6550], then the address of the
root of the DODAG is the compression reference for the source
Thubert, et al. Expires August 13, 2016 [Page 4]
Internet-Draft 6LoWPAN Inner Compression February 2016
address. It is also the compression reference for the destination
address in the absence of an RH3-6LoRH header.
5. Stateless Compression of the Source Address
This section covers the case of stateless address compression (SAC=0)
of the source address in a LOWPAN-IPHC.
If a compression reference Section 4.1 cannot be found, then
[RFC6282] applies. Else, the compression depends on the value of the
SAM bits as follows:
00: 128 bits. The full address is carried in-line
01: 64 bits. The first 64-bits of the address are elided and
obtained from the compression reference; the remaining 64 bits are
carried in-line
10: 16 bits. The first 112 bits of the address are elided and
obtained from the compression reference; the remaining 16 bits are
carried in-line
11: 0 bits. The address is fully elided, it is the same as the
compression reference.
6. Stateless Compression of the Destination Address
This section covers the case of stateless unicast address compression
(M=0, DAC=0) of the destination address in a LOWPAN-IPHC.
If a compression reference Section 4.2 cannot be found, then
[RFC6282] applies. Else, the compression depends on the value of the
DAM bits as follows:
00: 128 bits. The full address is carried in-line
01: 64 bits. The first 64-bits of the address are elided and
obtained from the compression reference; the remaining 64 bits are
carried in-line
10: 16 bits. The first 112 bits of the address are elided and
obtained from the compression reference; the remaining 16 bits are
carried in-line
11: 0 bits. The address is fully elided, it is the same as the
compression reference.
Thubert, et al. Expires August 13, 2016 [Page 5]
Internet-Draft 6LoWPAN Inner Compression February 2016
7. Security Considerations
The security considerations of [RFC4944] and [RFC6282] apply.
8. IANA Considerations
This document does not have requirements for IANA.
9. Acknowledgments
The authors wish to thank Thomas Watteyne, Maria-Rita Palatella,
Aurelie Sfez and Miguel Angel Reina Ortega for organizing the 6TiSCH
PlugTest with the ETSI.
10. References
10.1. Normative References
[I-D.ietf-6lo-routing-dispatch]
Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
"6LoWPAN Routing Header", draft-ietf-6lo-routing-
dispatch-04 (work in progress), January 2016.
[IEEE802154]
IEEE standard for Information Technology, "IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
Thubert, et al. Expires August 13, 2016 [Page 6]
Internet-Draft 6LoWPAN Inner Compression February 2016
10.2. Informative References
[I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work
in progress), November 2015.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012,
<http://www.rfc-editor.org/info/rfc6554>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
Authors' Addresses
Pascal Thubert (editor)
Cisco Systems
Building D - Regus
45 Allee des Ormes
BP1200
MOUGINS - Sophia Antipolis 06254
FRANCE
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Thubert, et al. Expires August 13, 2016 [Page 7]
Internet-Draft 6LoWPAN Inner Compression February 2016
Xavier Vilajosana
Universitat Oberta de Catalunya
156 Rambla Poblenou
Barcelona, Catalonia 08018
Spain
Phone: +34 (646) 633 681
Email: xvilajosana@uoc.edu
Simon Duquennoy
Inria
40, avenue Halley
Villeneuve d'Ascq 59650
France
Phone: +33 768227731
Email: simon.duquennoy@inria.fr
Thubert, et al. Expires August 13, 2016 [Page 8]