6lo working group                                             C. Bormann
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Standards Track                        October 12, 2014
Expires: April 15, 2015


               NHC compression for RPL Packet Information
                     draft-bormann-6lo-rpl-mesh-02

Abstract

   This short draft provides a straw man for the RPL Packet Information
   (RPI) NHC compression, a method to compress RPL Option [RFC6553]
   information within 6lowpan-style ("6lo") adaptation layers.

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 15, 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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Bormann                  Expires April 15, 2015                 [Page 1]


Internet-Draft NHC compression for RPL Packet Information   October 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The NHC escape mechanism  . . . . . . . . . . . . . . . . . .   2
   3.  RPI_NHC Encoding  . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security considerations . . . . . . . . . . . . . . . . . . .   8
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     10.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   [I-D.thubert-6man-flow-label-for-rpl] defines a way to compress
   information from the [RFC6553] RPL Option, for inclusion in an IPv6
   flow label.  The present draft shows how to carry the same
   information in a RPL Packet Information (RPI) NHC compression header,
   without consuming a lot of the code space for NHC headers.

   The RPL Packet Information is added to the 6lo adaptation layer
   framework ([RFC4944], [RFC6282]) as a small number of additional NHC
   compression codes.

   (More background information in Section 6.)

1.1.  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 RFC 2119 [RFC2119].

2.  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:









Bormann                  Expires April 15, 2015                 [Page 2]


Internet-Draft NHC compression for RPL Packet Information   October 2014


           0   1   2   3   4   5   6   7
         +---+---+---+---+---+---+---+---+
         | 0 | 1 | 0 | 0 | 0 | 1 | X | Y |
         +---+---+---+---+---+---+---+---+

                        Figure 1: 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.

   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.

3.  RPI_NHC Encoding

   [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 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, a 8-bit
   RPLInstanceID (with some internal structure), and a 16-bit
   SenderRank.

   The SenderRank is the result of the DAGRank operation on the rank of
   the sender, here the DAGRank operation is defined in section 3.5.1
   as:

      DAGRank(rank) = floor(rank/MinHopRankIncrease)

   If MinHopRankIncrease is set to a multiple of 256, it appears that
   the least significant 8 bits of the SenderRank will be all zeroes and
   can be elided, in which case the SenderRank can be compressed into
   one byte.  This idea is used in [RFC6550] by defining
   DEFAULT_MIN_HOP_RANK_INCREASE as 256.  The RPI_NHC provides a
   compressed form for the RPI and is constructed as follows:




Bormann                  Expires April 15, 2015                 [Page 3]


Internet-Draft NHC compression for RPL Packet Information   October 2014


           0   1   2   3   4   5   6   7
         +---+---+---+---+---+---+---+---+
         | 1 | 0 | 0 | 0 | O | I | K |NH |
         +---+---+---+---+---+---+---+---+

                             Figure 2: RPI NHC

   The RPL_NHC is immediately followed by the RPLInstanceID, unless it
   is elided, and then the SenderRank, which is either compressed into
   one byte or fully inlined as the whole 2 bytes.  Bits in the RPL_NHC
   indicate whether the RPLInstanceID is elided and/or the SenderRank is
   compressed:

   O: The O bit is defined in [RFC6550] section 11.2.

   NH:  1-bit field.  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 field.  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 RPL_NHC contains the
      RPLInstanceID as specified in [RFC6550] section 5.1.

   K: 1-bit field.  If it is set, the SenderRank is be compressed into
      one byte, and the lowest significant byte is elided.  If it is not
      set, the SenderRank, is fully inlined as 2 bytes.

   R, and F bits:  The R and F bits are defined in [RFC6550] section
      11.2.  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.)

   In the following case, 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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |1|0|0|0|O|1|1|N|  SenderRank   |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In the following case, the RPLInstanceID is the Global RPLInstanceID
   0, but both bytes of the SenderRank are significant so it can not be
   compressed:



Bormann                  Expires April 15, 2015                 [Page 4]


Internet-Draft NHC compression for RPL Packet Information   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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |1|0|0|0|O|1|0|N|      SenderRank               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In the following case, the RPLInstanceID is not the Global
   RPLInstanceID 0, and the MinHopRankIncrease is a multiple of 256:

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |1|0|0|0|O|0|1|N| RPLInstanceID |  SenderRank   |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In the following case, 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1|0|0|0|O|0|0|N| RPLInstanceID |      SenderRank               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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].

4.  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?

   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?



Bormann                  Expires April 15, 2015                 [Page 5]


Internet-Draft NHC compression for RPL Packet Information   October 2014


   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 3.

   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.  Discussion

   (This section to be removed by the RFC editor.)

   Compared to [I-D.thubert-6man-flow-label-for-rpl], the 6lo-based
   approach used here has the following advantages:

   o  more efficient (in size) encoding possible

   o  avoids any entanglement with flow label from RFC 6437

   o  avoids any issues with undetected changes to flow label field,
      which might be:

      *  because the IPv6 header is not covered by a checksum

      *  because nodes that happen to become on-path use the flow label
         for something else

   o  nodes outside 6lo that do not need the compression do not have to
      deal with an alternate representations of the RFC 6553 information

   Compared to [I-D.toutain-6lo-local-extensions], RPL Information
   Header proposal is entirely focused on RFC 6553 So it may be possible
   to complete this focused draft much faster than a general approach.
   Also, the result is likely to be more efficient.

   Compared to [I-D.thubert-6lo-rpl-nhc], much more of the NHC space is
   left usable, e.g., leaving bits available to possibly eventually
   cover [RFC6554].




Bormann                  Expires April 15, 2015                 [Page 6]


Internet-Draft NHC compression for RPL Packet Information   October 2014


   Finally, this draft can be ignored by implementations not
   implementing RPL.

6.  Background

   Some more historical background about compression and RPL:\

   (This section to be removed by the RFC editor.)

   The ROLL WG has a routing protocol, RPL [RFC6550], that requires some
   data to be shipped around together with IP packets.  [RFC6553] and
   [RFC6554] define ways to do this that are consistent with the IP
   architecture: The RPL Option defined in [RFC6553] is a hop-by-hop
   option that provides RPL rank and instance-id, as well as a few
   flags; the Routing Header defined in [RFC6554] provides the source
   routing needed for downward-routed packets in RPL's dominant non-
   storing mode.

   Unfortunately, the overhead (signal-to-fluff ratio) for both
   representations is relatively high, and in a constrained environment,
   that matters.

   An obvious next step would have been looking at ways to do header
   compression.  Compressing RPL was extensively discussed, but mostly
   with a view to compressing the (control plane) ROLL messages carried
   in ICMPv6, not so much about the RPL information carried with the
   (data plane) IP packets themselves.  GHC [I-D.ietf-6lo-ghc] is trying
   to be a reasonably useful, but also reasonably general way to
   compress the control plane messages.

   For the data packets, the flow label (and its now predominant non-
   use) provides an attractive place in the IPv6 packets to ship around
   the [RFC6553] information, but not the potentially more substantial
   [RFC6554] information.  In 6lo networks, normally [RFC6282]
   compresses away empty flow labels, but it is cheap to put them in, so
   a flow label really only costs 3 bytes (instead of the 8 bytes a RPL
   Option [RFC6553] costs).  The most useful information from [RFC6553]
   can be stuffed into 19 bits, as demonstrated by
   [I-D.thubert-6man-flow-label-for-rpl].

   [RFC6282] has extension points (GHC uses one of them), but not really
   useful ones for the ROLL data plane.  So it appears it never occurred
   to us that the best way to handle these 19 bits is to actually
   sidestep [RFC6282], and use the existing extension points of
   [RFC4944].  Until Laurent Toutain showed one way of doing this
   [I-D.toutain-6lo-local-extensions].  The previous version of the
   present draft just went from there and used Laurent's idea for
   compressing the [RFC6553] option, in a way that is as efficient as



Bormann                  Expires April 15, 2015                 [Page 7]


Internet-Draft NHC compression for RPL Packet Information   October 2014


   (or, in most cases, actually more efficient than) using the flow
   label opportunity.

   The present draft is a variation of the idea to use NHC header
   compression for representing the [RFC6553] RPL option
   [I-D.thubert-6lo-rpl-nhc].  It may be slightly less efficient than
   the previous version of this draft, but it is much more conservative
   in consuming NHC code point space than [I-D.thubert-6lo-rpl-nhc].

   In summary, this means the present draft intends to replace the flow
   label bit allocation of [I-D.thubert-6man-flow-label-for-rpl].  It
   does not cover the "license-to-drop" the flow label that
   [I-D.thubert-6man-flow-label-for-rpl] implies (and that is denied by
   [RFC6437]).  It also does not cover the compression of [RFC6554]
   source routing information, but does provide an extension point for
   adding that later.

7.  IANA considerations

   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]

8.  Security considerations

   The security considerations of [RFC4944], [RFC6282], and [RFC6553]
   apply.

9.  Acknowledgments

   This document is based on the ideas in the specifications
   [I-D.thubert-6man-flow-label-for-rpl] and [I-D.thubert-6lo-rpl-nhc]
   and has borrowed a lot of text from the latter.  Its use of the RFC
   4944 framework was inspired by [I-D.toutain-6lo-local-extensions].
   Ralph Droms supplied a number of helpful comments on the -00 draft.
   The discussion in the 6man and roll working groups also was helpful.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.





Bormann                  Expires April 15, 2015                 [Page 8]


Internet-Draft NHC compression for RPL Packet Information   October 2014


   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [RFC6282]  Hui, J. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              September 2011.

   [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.

10.2.  Informative References

   [I-D.ietf-6lo-ghc]
              Bormann, C., "6LoWPAN Generic Compression of Headers and
              Header-like Payloads (GHC)", draft-ietf-6lo-ghc-05 (work
              in progress), September 2014.

   [I-D.thubert-6lo-rpl-nhc]
              Thubert, P., "A compression mechanism for the RPL option",
              draft-thubert-6lo-rpl-nhc-01 (work in progress), August
              2014.

   [I-D.thubert-6man-flow-label-for-rpl]
              Thubert, P., "The IPv6 Flow Label within a LLN domain",
              draft-thubert-6man-flow-label-for-rpl-05 (work in
              progress), August 2014.

   [I-D.toutain-6lo-local-extensions]
              Toutain, L., "6LoWPAN Local Extensions", draft-toutain-
              6lo-local-extensions-00 (work in progress), June 2014.

   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
              "IPv6 Flow Label Specification", RFC 6437, November 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.







Bormann                  Expires April 15, 2015                 [Page 9]


Internet-Draft NHC compression for RPL Packet Information   October 2014


   [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, March
              2012.

Author's Address

   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63921
   Email: cabo@tzi.org




































Bormann                  Expires April 15, 2015                [Page 10]