6lo P. Thubert, Ed. Internet-Draft Cisco Updates: 6282 (if approved) C. Bormann Intended status: Standards Track TZI Expires: April 27, 2015 October 24, 2014 A compression mechanism for the RPL option draft-thubert-6lo-rpl-nhc-02 Abstract This specification defines the RPL Packet Information (RPI) NHC compression, a method to compress RPL Option (RFC6553) information within 6LoWPAN-style ("6lo") adaptation layers. This extends 6LoWPAN Header Compression (RFC6282), saving up to 48 bits in each frame compared to the uncompressed form in RFC 6553. 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 April 27, 2015. Copyright Notice Copyright (c) 2014 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 & Bormann Expires April 27, 2015 [Page 1] Internet-Draft A compression mechanism for the RPL option October 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Updating RFC 6282 . . . . . . . . . . . . . . . . . . . . . . 4 4. The RPL Packet Information NHC . . . . . . . . . . . . . . . 4 4.1. Compressing the RPLInstanceId . . . . . . . . . . . . . . 5 4.2. Compressing the SenderRank . . . . . . . . . . . . . . . 5 4.3. The RPI_NHC encoding . . . . . . . . . . . . . . . . . . 5 4.3.1. The Greedy Approach . . . . . . . . . . . . . . . . . 7 4.3.2. The Conservative Approach . . . . . . . . . . . . . . 7 4.3.3. The Efficient Approach . . . . . . . . . . . . . . . 8 4.3.3.1. The NHC escape mechanism . . . . . . . . . . . . 8 4.3.3.2. RPI_NHC Encoding . . . . . . . . . . . . . . . . 9 4.3.3.3. Operation . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The design of Low Power and Lossy Networks (LLNs) is generally focused on saving energy, which is the most constrained resource of all. The other constraints, such as the memory capacity and the duty cycling of the LLN devices, derive from that primary concern. Energy is typically available from batteries that are expected to last for years, or 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.14.5 [IEEE802154] is limited to 127 bytes per frame. The need to compress IPv6 packets over IEEE 802.14.5 led to the 6LoWPAN Header Compression [RFC6282] work (6LoWPAN-HC). The Routing Protocol for Low Power and Lossy Networks [RFC6550] (RPL) is designed to optimize the routing operations in constrained LLNs. Thubert & Bormann Expires April 27, 2015 [Page 2] Internet-Draft A compression mechanism for the RPL option October 2014 As part of this optimization, RPL requires the addition of RPL Packet Information (RPI) in every packet, as defined in Section 11.2 of [RFC6550]. ------+--------- ^ | Internet | | | Native IPv6 +-----+ | | | Border Router (RPL Root) ^ | ^ | | | | | +-----+ | | | IPv6 in | | | | IPv6 + RPI o o o o | | | o o o o o o o o o | | | o o o o o o o o o o | | | o o o o o o o o o | | | o o o o o o o o v v v o o o o LLN Figure 1: IP-in-IP Encapsulation within the LLN The RPI is used to tag the packet with the RPL Instance ID and other information that RPL requires for its operation within the RPL domain. In particular, the SenderRank, which is the scalar metric computed by an specialized Objective Function such as [RFC6552], indicates the Rank of the sender and is modified at each hop. The SenderRank allows to validate that the packet progresses in the expected direction, either upwards or downwards, along the DODAG. RPL defines the RPL Option for Carrying RPL Information in Data-Plane Datagrams [RFC6553] to transport the RPI, which is carried in an IPv6 Hop-by-Hop Options Header [RFC2460], typically consuming eight bytes per packet. 6TiSCH [I-D.ietf-6tisch-architecture] specifies the operation of IPv6 over the TimeSlotted Channel Hopping [I-D.ietf-6tisch-tsch] (TSCH) mode of operation of IEEE 802.14.5. The architecture requires the use of both 6LoWPAN HC and RPL over IEEE 802.14.5. Because it inherits the constraints on the frame size from the MAC layer, 6TiSCH cannot afford to spend 8 bytes per packet on the RPI. Hence the requirement for a 6LoWPAN header compression of the RPI. This specification extends the 6lo adaptation layer framework ([RFC4944], [RFC6282]) to carry the same information in a 6LoWPAN RPL Packet Information (RPI) NHC Next-header compression (NHC) header, usually eliminating the Hop-by-Hop Options Header saving up to six bytes per packet. Thubert & Bormann Expires April 27, 2015 [Page 3] Internet-Draft A compression mechanism for the RPL option October 2014 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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 [RFC6550]. The term "byte" is used in its now customary sense as a synonym for "octet". 3. Updating RFC 6282 This specification proposes a new 6LoWPAN Next Header Compression (NHC) for the RPL option [RFC6553], called RPI_NHC, to be placed in a packet that is compressed per [RFC6282]. It updates [RFC6282] in that the "necessary property of encoding headers using LOWPAN_NHC" becomes that "the immediately preceding header must be encoded using either LOWPAN_IPHC, RPI_NHC or LOWPAN_NHC". Additionally, the necessary property of encoding headers using RPI_NHC is that the immediately preceding header must be encoded using either LOWPAN_IPHC or LOWPAN_NHC. (Discuss: Is this really an update of RFC 6282 or a straightforward addition to it?) 4. The RPL Packet Information NHC [RFC6550], Section 11.2, specifies the RPL Packet Information (RPI) as a set of fields that are to be added to the IP packets for the purpose of Instance Identification, as well as Loop Avoidance and Detection. [RFC6553] defines an encoding for the RPI as a RPL option located in the IPv6 Hop-by-hop Option Header. The present NHC compression mechanism compresses IPv6 Hop-by-hop Headers that contain only that RPL option. The fields in the RPI include an 'O', an 'R', and an 'F' bit, an 8-bit RPLInstanceID (with some internal structure), and a 16-bit SenderRank. Thubert & Bormann Expires April 27, 2015 [Page 4] Internet-Draft A compression mechanism for the RPL option October 2014 This section defines the format of the RPL Packet Information NHC (RPI_NHC) that is used to compress the RPI in 6LoWPAN networks. 4.1. Compressing the RPLInstanceId RPL Instances are discussed in [RFC6550], Section 5. A number of simple use cases will not require more than one instance, and in such a case, the instance is expected to be the global Instance 0. A global RPLInstanceID is encoded in a RPLInstanceID field as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0| ID | Global RPLInstanceID in 0..127 +-+-+-+-+-+-+-+-+ Figure 2: RPLInstanceID Field Format for Global Instances For the particular case of the global Instance 0, the RPLInstanceID field is all zeroes. This specification allows to elide a RPLInstanceID field that is all zeroes, and defines a 'I' flag that, when set, signals that the field is elided. 4.2. Compressing the SenderRank The SenderRank is the result of the DAGRank operation on the rank of the sender; here the DAGRank operation is defined in [RFC6550], Section 3.5.1, as: DAGRank(rank) = floor(rank/MinHopRankIncrease) If MinHopRankIncrease is set to a multiple of 256, the least significant 8 bits of the SenderRank will be all zeroes; by eliding those, the SenderRank can be compressed into a single byte. This idea is used in [RFC6550] by defining DEFAULT_MIN_HOP_RANK_INCREASE as 256 and in [RFC6552] that defaults MinHopRankIncrease to DEFAULT_MIN_HOP_RANK_INCREASE. This specification allows to encode the SenderRank as either one or two bytes, and defines a 'K' flag that, when set, signals that a single byte is used. 4.3. The RPI_NHC encoding [RFC6553] defines an encoding for the RPL information as a RPL Option located in an IPv6 Hop-by-Hop Option Header. The RPI_NHC provides a compressed form for that information and is constructed as follows: Thubert & Bormann Expires April 27, 2015 [Page 5] Internet-Draft A compression mechanism for the RPL option October 2014 The RPI_NHC is immediately followed by the RPLInstanceID, unless that is elided (I=1), and then the SenderRank, which is either compressed into one byte (K=1) or fully inlined as the whole 2 bytes (K=0). Bits in the RPI_NHC indicate whether the RPLInstanceID is elided and/ or the SenderRank is compressed: O, R, and F bits: The O, R, and F bits as defined in [RFC6550], Section 11.2. NH: 1-bit flag. The Next Header (NH) bit is defined in [RFC6282], Section 4.2, and it is set to indicate that the next header is encoded using LOWPAN_NHC I: 1-bit flag. If it is set, the Instance ID is elided and the RPLInstanceID is the Global RPLInstanceID 0. If it is not set, the byte immediately following the RPI_NHC contains the RPLInstanceID as specified in [RFC6550], Section 5.1. K: 1-bit flag. If it is set, the SenderRank is compressed into one byte, and the least significant byte is elided. If it is not set, the SenderRank is fully inlined as 2 bytes. In Figure 3, the RPLInstanceID is the Global RPLInstanceID 0, and the MinHopRankIncrease is a multiple of 256 so the least significant byte is all zeroes and can be elided: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NHC: I=1, K=1 | SenderRank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The most compressed RPI_NHC In Figure 4, the RPLInstanceID is the Global RPLInstanceID 0, but both bytes of the SenderRank are significant so it can not be compressed: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NHC: I=1, K=0 | SenderRank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Eliding the RPLInstanceID In Figure 5, the RPLInstanceID is not the Global RPLInstanceID 0, and the MinHopRankIncrease is a multiple of 256: Thubert & Bormann Expires April 27, 2015 [Page 6] Internet-Draft A compression mechanism for the RPL option October 2014 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NHC: I=0, K=1 | RPLInstanceID | SenderRank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Compressing SenderRank In Figure 6, the RPLInstanceID is not the Global RPLInstanceID 0, and both bytes of the SenderRank are significant: 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 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NHC: I=0, K=0 | RPLInstanceID | SenderRank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Least compressed form of RPI_NHC The next sections provide alternatives for format of the RPI_NHC. 4.3.1. The Greedy Approach The RPI_NHC is constructed as follows: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 0 | I | K | O | R | F |NH | +---+---+---+---+---+---+---+---+ Figure 7: The RPI_NHC, Greedy Version Depending on the RPLInstanceID and the MinHopRankIncrease, the proposed format thus squeezes the RPL information into 16 to 32 bits, which compares to 64 bits when using a Hop-by-hop option with the RPL option as specified in [RFC6553]. (This is called the "greedy" approach as it consumes 1/4 of the NHC space just for the RPI compression.) 4.3.2. The Conservative Approach In this approach, the encoding of the RPL Packet Information takes two bytes: one byte to indicate the NH type, and then one byte to signal the compressed information. Thubert & Bormann Expires April 27, 2015 [Page 7] Internet-Draft A compression mechanism for the RPL option October 2014 The NH type is indicated in an extension to existing LOWPAN_NHC encodings. Section 4.2 of [RFC6553] defines LOWPAN_NHC encodings for IPv6 Extension Headers as in Figure 8: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 1 | 1 | 0 | EID |NH | +---+---+---+---+---+---+---+---+ Figure 8: IPv6 Extension Header Encoding Values 5 and 6 of the IPv6 Extension Header ID (EID) are still reserved. This specification uses EID of 5 to indicate that the next byte is a RPI_NHC. The RPI_NHC is constructed as shown in Figure 9: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | I | K | O | R | F | reserved | +---+---+---+---+---+---+---+---+ Figure 9: The RPI_NHC, Conservative Version The bits 5 to 7 of the RPI_NHC are reserved for future use and MUST be sent as zero. (This is called the "conservative" approach as it consumes only 1/256 of the NHC space.) 4.3.3. The Efficient Approach 4.3.3.1. The NHC escape mechanism The NHC space of [RFC6282] is limited to 256 code points. For the case some infrequent bit combinations do not fit into the 256 code points, this specification assigns four code points: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 1 | 0 | 0 | 0 | 1 | X | Y | +---+---+---+---+---+---+---+---+ Figure 10: NHC Escape Codes Each NHC escape code is followed by a further NHC code point. The latter MUST be a code point for which special semantics for a preceding escape code are defined, i.e., an escape code MUST NOT be used in front of an NHC code point that does not define special semantics for this escape code. Thubert & Bormann Expires April 27, 2015 [Page 8] Internet-Draft A compression mechanism for the RPL option October 2014 An escape code followed by another escape code supplies additional semantics; again, a sequence of such escape codes MUST NOT be used unless the final NHC code following this sequence defines the semantics for the specific sequence. 4.3.3.2. RPI_NHC Encoding The RPI_NHC provides a compressed form for the RPI and is constructed as follows: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 0 | 0 | 0 | O | I | K |NH | +---+---+---+---+---+---+---+---+ Figure 11: RPI NHC, efficient version The R and F bits, as defined in [RFC6550], Section 11.2, are represented as follows: If R=0 and F=0, the NHC code is used as defined above. If either is non-zero, a single escape code with X=R and Y=F is prepended in front of the NHC code. (An escape code with X=0 and Y=0 MUST NOT be used with RPI_NHC. A sequence of two or more escape codes MUST NOT be used with RPI_NHC.) Depending on the RPLInstanceID and the MinHopRankIncrease, the proposed format thus squeezes the RPI into 16 to 40 bits, which compares to 64 bits when using a Hop-by-hop option with the RPL option as specified in [RFC6553]. (This is called the "efficient" approach as it consumes only 1/16 of the NHC space, but, depending on the frequency of set R or set F flags, is almost as efficient as the greedy approach.) 4.3.3.3. Operation A 6lo compressor that is about to create either an RFC 6282 IPHC header [RFC6282] or a Frag1 header [RFC4944] and finds a Hop-by-Hop Options header [RFC2460] with an RPL Option [RFC6553] in it, performs the following checks: 1. Does the compression scheme apply? I.e.: A. is no sub-tlv present in the RPL Option? B. is the RPL Option the only option in the Hop-by-Hop Options header? Thubert & Bormann Expires April 27, 2015 [Page 9] Internet-Draft A compression mechanism for the RPL option October 2014 2. Does the additional compression for I=1 apply? I.e.: is RPLInstanceID == 0? 3. Does the additional compression for K=1 apply? I.e.: is SenderRank < 256? 4. Is both R=0 and F=0, or do we need an escape code? If check 1 succeeds, the compressor removes the Hop-by-Hop Options header (replacing the zero-valued next header field in the IPv6 header with the value of the next header field of the Hop-by-Hop Options header), and, depending on the outcome of check 2 and 3, generates an RPI_NHC Header with I and K set from the payload information in the RPL Option. If one or both of R and F are non- zero (check 4), it precedes the first byte in the RPI_NHC header with an escape code with X=R and Y=F. It then continues generating the RFC 6282 IPHC or RFC 4944 Frag1 header, filling in the continuation of the RPL Information header as defined in Section 4.3.3.2. A 6lo decompressor that encounters a RPL Information header reverses this process, creating a Hop-by-Hop Options header with a single RPL Option carrying the information in the RPL Information header. 5. Security Considerations The security considerations of [RFC4944], [RFC6282], and [RFC6553] apply. Using a compressed format as opposed to the full inline RPL option is logically equivalent and does not create an opening for a new threat when compared to [RFC6553]. 6. IANA Considerations (greedy variant:) This document updates IANA registry for the LOWPAN_NHC defined in [RFC6282] and assigns the previously unassigned: 10IKORFN: RPL Information [RFCthis] Capital letters in bit positions represent class-specific bit assignments. IKORF represents variables specific to RPL Information compression defined in Section 4. N indicates whether or not additional LOWPAN_NHC encodings follow, as defined in Section 4.2 of [RFC6553]. (efficient variant:) Thubert & Bormann Expires April 27, 2015 [Page 10] Internet-Draft A compression mechanism for the RPL option October 2014 This draft requests IANA to assign the following LOWPAN_NHC types in the "IPv6 Low Power Personal Area Network Parameters" registry: 010001XY: Escape X=0/Y=0 to X=1/Y=1 [RFCthis] 1000IOKN: RPL Information [RFCthis] 7. Acknowledgements The author wishes to thank Laurent Toutain for suggesting this work and and Martin Turon for his constructive contributions. Ralph Droms supplied a number of helpful comments on the -00 draft of [I-D.bormann-6lo-rpl-mesh], which was superseded by the present document, turning into the "efficient approach". The discussion in the 6man and roll working groups also was helpful. 8. References 8.1. Normative References [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", June 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011. [RFC6550] Winter, T., Thubert, P., 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, March 2012. [RFC6552] Thubert, P., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, March 2012. Thubert & Bormann Expires April 27, 2015 [Page 11] Internet-Draft A compression mechanism for the RPL option October 2014 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, March 2012. 8.2. Informative References [I-D.bormann-6lo-rpl-mesh] Bormann, C., "NHC compression for RPL Packet Information", draft-bormann-6lo-rpl-mesh-02 (work in progress), October 2014. [I-D.ietf-6tisch-architecture] Thubert, P., Watteyne, T., and R. Assimiti, "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e", draft-ietf-6tisch-architecture-03 (work in progress), July 2014. [I-D.ietf-6tisch-tsch] Watteyne, T., Palattella, M., and L. Grieco, "Using IEEE802.15.4e TSCH in an IoT context: Overview, Problem Statement and Goals", draft-ietf-6tisch-tsch-02 (work in progress), October 2014. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, January 2014. Authors' Addresses Pascal Thubert (editor) Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 4 97 23 26 34 Email: pthubert@cisco.com Thubert & Bormann Expires April 27, 2015 [Page 12] Internet-Draft A compression mechanism for the RPL option October 2014 Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Thubert & Bormann Expires April 27, 2015 [Page 13]