Network Working Group                                        A. Minaburo
Internet-Draft                                                    Acklio
Intended status: Informational                                L. Toutain
Expires: October 21, 2016      Institut MINES TELECOM ; TELECOM Bretagne
                                                          April 19, 2016


                       LP-WAN Compression Context
              draft-toutain-lp-wan-compression-context-00

Abstract

   This documents describes a way to adapt the formal notation to the
   IoT context, especially for LP-WAN communication where packet size is
   drastically limited.  It is also necessary to simplify several
   notation and avoid a specific notation.  Concept described in
   [RFC4997]  may be written in CBOR or YANG.

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 October 21, 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




Minaburo & Toutain      Expires October 21, 2016                [Page 1]


Internet-Draft         LP-WAN Compression Context             April 2016


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   Robust Header Compression (RoHC) [RFC3095] has been originally
   designed to compress the IP/UDP/RTP headers mainly to allow the use
   of SIP on 3G networks.  The protocol has been extended by a Formal
   Notation (FN) [RFC4997] allowing to compress any protocol headers.
   Original uncompressed packet header format is described using that
   formal notation and several compressed packet header are derived.
   RoHC state machine can chose which compress format to use regarding
   the context evolution.  RoHC state machine progressively reduce the
   header size by sending only changing fields either integrally or
   through delta.  A context must be established on the sender and the
   receiver to reconstruct the header.  Several modes and several
   degrees of compression are available.  This document [1] gives an
   overview of RoHC behavior.

   This documents describes a way to adapt the formal notation to the
   IoT context, especially for LP-WAN communication where packet size is
   drastically limited [I-D.minaburo-lp-wan-gap-analysis] . It is also
   necessary to simplify several notation and avoid a specific notation.
   Concept described in [RFC4997]  may be written in CBOR or YANG.

2.  Formal Notation

   [RFC4997]  annex A gives a very good tutorial on the formal notation
   language and how different kinds of compressed headers that may be
   defined regarding the field behavior.  The objective of the rest of
   this chapter is to take elements that can be useful is the LP-WAN
   context.

     eg_header
        {
          UNCOMPRESSED {
            field_1        [ 2 ];
          }

          COMPRESSED initial_definition {
            field_1       =:= fct(x);
          }
        }


                 Figure 1: Simplest header representation





Minaburo & Toutain      Expires October 21, 2016                [Page 2]


Internet-Draft         LP-WAN Compression Context             April 2016


   Figure 1 represents a very simple header composed of a single field.
   Two representations of the field are described: the uncompressed and
   the compressed one.  The link between the both is done through the
   name: field_1 in the example.

   The link between the compressed and decompressed value is done by a
   function.  This function is bi-directional, which means that "fct" in
   the example can be used to go from the uncompressed value to the
   compressed one or vice versa.  The symbol "=:=" describes the call to
   that fonction.  Note that since the fonction is bi-directionnal, the
   definition could have been done also in the uncompressed description.
   Function can take some arguments ("x" in the example).

   The size of the field as to be defined, at least in the uncompressed
   description and given between square brackets.  In the example, the
   length is 2 bits.

   eg_header
        {
          UNCOMPRESSED {
            version_no   [ 2 ];
            type         [ 2 ];
            flow_id      [ 4 ];
            sequence_no  [ 4 ];
            flag_bits    [ 4 ];
          }
         COMPRESSED initial_definition {
            version_no  =:= irregular(2);
            type        =:= irregular(2);
            flow_id     =:= irregular(4);
            sequence_no =:= irregular(4);
            flag_bits   =:= irregular(4);
          }
        }


                        Figure 2: Null compression

   This example, taken from [RFC4997]  annex A, represents a null
   compression, since the compressed and uncompressed headers will be
   exactly the same.  The function "irregular" describes the field
   behavior as non predictable, therefore the value has to be sent.  The
   argument is the size of the field.

   The example continues with a effective compression.






Minaburo & Toutain      Expires October 21, 2016                [Page 3]


Internet-Draft         LP-WAN Compression Context             April 2016


   eg_header
        {
          UNCOMPRESSED {
            version_no     [ 2 ];
            type           [ 2 ];
            flow_id        [ 4 ];
            sequence_no    [ 4 ];
            abc_flag_bits  [ 3 ];
            reserved_flag  [ 1 ];
          }
          COMPRESSED obvious {
            version_no    =:= uncompressed_value(2, 1);
            type          =:= irregular(2);
            flow_id       =:= static;
            sequence_no   =:= lsb(0, -3);
            abc_flag_bits =:= irregular(3);
            reserved_flag =:= uncompressed_value(1, 0);
          }
        }


                       Figure 3: Header compression

   Several functions are called:

   o  uncompressed_value (2, 1) indicates that the value of the field is
      always '01'. therefore it can be suppressed from the compressed
      header or added to the uncompressed header.

   o  static indicates that the field does not change during the
      transmission of a specific flow.  Static fields are not sent in
      the compressed format, but the initial value has to be known by
      both sides by another mean.

   o  lsb allows to send in few bits a small modification in the field
      value.

3.  Compression of IPv6 and UDP

   One possible way to compress header in LP-WAN is to use a shim.  A
   shim is a byte between layer 2 and 3 describing a compressed protocol
   stack.  In the example, Figure 4 CoAP is used both for configuration
   and for user's applications.  The first stack uses UDP ports 123 and
   124 and the other UDP ports 8356.  Respectively, shim 0 and 1 are
   associated to these stacks.  In this example, CoAP is not compressed.
   We also suppose that the source and destination addresses are link-
   local.




Minaburo & Toutain      Expires October 21, 2016                [Page 4]


Internet-Draft         LP-WAN Compression Context             April 2016


   |
   |auth|cool |
   +----------+---------+
   |   CoAP   |   CoAP  |
   +....||....+...||....+
   :   UDP    :  UDP    :
   :..........:.........:
   :   6LP    :  6LP    :
   +-------------------------------------------------------+
   |     SHIM                                              |
   +-------------------------------------------------------+
   |     LP-WAN L2 technologies                            |
   +-------------------------------------------------------+

              Figure 4: Simplified Protocol Stack for LP-WAN

   Figure 5 describes the definition of the IPv6/UDP protocol stack
   based on [RFC5225].

   IPv6_udp_compression {
     UNCOMPRESSED {
       version         =:= uncompressed_value(4, 6)    [   4 ];
       tos_tc          =:= uncompressed_value(8, 0)    [   8 ];
       flow_label      =:= uncompressed_value(20, 0)   [  20 ];
       payload_length  =:= inferred_ip_v6_length       [  16 ];
       next_header     =:= uncompressed_value(8, 17)   [   8 ];
       ttl_hopl        =:= uncompressed_value(8, 64)   [   8 ];
       src_addr_prf    =:= uncompressed_value(64, FE80)[   64];
       src_addr_iid    =:= inferred_mac_src_iid(64, FE80)[   64];
       dst_addr_prf   =:= uncompressed_value(64, FE80) [   64];
       dst_addr_iid   =:= inferred_mac_dst_iid(64, FE80)[   64];

       src_port                                     [ 16 ];
       dst_port                                     [ 16 ];
       udp_length =:= inferred_udp_length           [ 16 ];
       checksum   =:= inferred_udp_chk              [ 16 ];
     }


                   Figure 5: IPv6/UDP header description

   The main difference is the split in two fields of the source and
   destination address to be closer to 6LoWPAN [RFC6282].  Two
   compression methods will have to be defined to take the IID from the
   MAC address.  Some compression methods are also used to elude the
   length and checksum during the transmission.





Minaburo & Toutain      Expires October 21, 2016                [Page 5]


Internet-Draft         LP-WAN Compression Context             April 2016


     COMPRESSED shim_0{
          ENFORCE(next_header.UVALUE == 17)
          ENFORCE(src_port.UVALUE == 123)
          ENFORCE(dst_port.UVALUE == 124)
          shim =:= uncompress_value (8, 0) [8]
        }

        COMPRESSED shim_1{
          ENFORCE(next_header.UVALUE == 17)
          ENFORCE(src_port.UVALUE == 8356)
          ENFORCE(dst_port.UVALUE == 8356)
          shim =:= uncompress_value (8, 1) [8]
        }


                 Figure 6: IPv6/UDP compression to a shim

   The compression methods are defined Figure 3.  They use the ENFORCE
   statement from the RoHC-FN.  UVALUE also is used to access to the
   uncompressed value of a field.  Therefore, to send shim 0, the
   protocol must be UDP and the port correspond to 123 and 124.  The
   approach for shim 1 is the same.

   NOTE: the description will differ for the sender and receiver since
   source and destination ports need to be swapped.  It could be
   interested to find a more generic description.

4.  6WIDe representation

   The use of the formal notation may be to complex for nodes.  A more
   compact representation should be used.  CBOR is a good candidate.
   This is a first attempt to transform the description seen in
   Section 3.  This also can derive from a Yang model.

   A compression/decompression context is represented by an CBOR array
   containing in the first element a array of the fields present in the
   uncompressed header and reference to functions doing the conversion
   (this can be also an array when function ask for arguments).  This is
   followed by one on several compressed headers.  Compressed header are
   composed of two arrays.  The first one correspond to the predicate
   allowing to access the compression (sort of ENFORCE).  The second one
   contains the field of the compressed header followed by a reference
   to a function to do the conversion.  If the reference is negative, it
   creates a new field of this size.







Minaburo & Toutain      Expires October 21, 2016                [Page 6]


Internet-Draft         LP-WAN Compression Context             April 2016


     [ // beginning of the compression/decompression context
       [ // first element, uncompressed packet description
           [size in bit, function] // field 1
           [size in bit, function] // field 2
           [size in bit, function] // field 3
           ....
       ] // end of first element
       [ // first compressed format
         [ // predicates
            [ref to field, value] // field == value
             ....
         ]
         [ // fields in compressed format
             [ref to field, function] // compression of a field
             [-length, function]      // new field of length size

         ]
       ] // end of first compressed format
       [ // second compressed format
         ....
       ]
        ....
     ] // end of the compression/decompression context


                         Figure 7: CBOR framework

   The IPv6/UDP stack can be represented like this:























Minaburo & Toutain      Expires October 21, 2016                [Page 7]


Internet-Draft         LP-WAN Compression Context             April 2016


   [ // begin of the compress context
     [ // original packet description
       [4, [0, 4, 6]], //version          0
       [8, [0, 8, 0]], //tos_tc           1
       [20,[0, 20, 0]], // flow_label     2
       [16,15] // length                  3
       [8, [0, 8, 17]], // NH             4
       [8, [0, 8, 64]], // HL             5
       [64, [0, 64, FE80]], // SRC pref   6
       [64, 16], // SRC IID               7
       [64, [0, 64, FE80]], // DST pref   9
       [64, 17] // DST IID               10

       [16] // src port                  11
       [16] // dst port                  12
       [16, 18] // length                13
       [16, 19] // chk                   14
     ]

                         Figure 8: CBOR framework

   It is about 100 bytes long, note that the function 0 takes two
   arguments as in RoHC-FN.  The first one corresponding to the size can
   be removed.  We also suppose arbitrarily that value 15 correspond to
   IPv6 length computation, 16 and 17 to IID computation.  The
   compressed format can be described with way.

    [ // first compressed format
          [ // predicates
            [4, 17], // NH == 17
            [11, 123] // src port == 123
            [12, 124] // dst port == 124
          ]
          [
            [-8, [0, 8, 0]] // SHIM 0
          ]
        ]
   ]


                         Figure 9: CBOR framework

   -8 state for the creation of a new field of 8 bits in the compress
   format.  Function 0 set the value to 0.







Minaburo & Toutain      Expires October 21, 2016                [Page 8]


Internet-Draft         LP-WAN Compression Context             April 2016


5.  CoAP compression

   Work to be done to define a header with coap we need TLV.  We can use
   negative CBOR value: -1 is a CoAP TLV, -2 a token (refers to token
   size in the header).

6.  References

6.1.  Normative References

   [I-D.minaburo-lp-wan-gap-analysis]
              Minaburo, A., Pelov, A., and L. Toutain, "LP-WAN GAP
              Analysis", draft-minaburo-lp-wan-gap-analysis-01 (work in
              progress), February 2016.

   [RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
              Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
              K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
              Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
              Compression (ROHC): Framework and four profiles: RTP, UDP,
              ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095,
              July 2001, <http://www.rfc-editor.org/info/rfc3095>.

   [RFC4997]  Finking, R. and G. Pelletier, "Formal Notation for RObust
              Header Compression (ROHC-FN)", RFC 4997,
              DOI 10.17487/RFC4997, July 2007,
              <http://www.rfc-editor.org/info/rfc4997>.

   [RFC5225]  Pelletier, G. and K. Sandlund, "RObust Header Compression
              Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
              UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008,
              <http://www.rfc-editor.org/info/rfc5225>.

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

6.2.  URIs

   [1] http://dl.acm.org/citation.cfm?id=2728090

Authors' Addresses








Minaburo & Toutain      Expires October 21, 2016                [Page 9]


Internet-Draft         LP-WAN Compression Context             April 2016


   Ana Minaburo
   Acklio
   2bis rue de la Chataigneraie
   35510 Cesson-Sevigne Cedex
   France

   Email: ana@ackl.io


   Laurent Toutain
   Institut MINES TELECOM ; TELECOM Bretagne
   2 rue de la Chataigneraie
   CS 17607
   35576 Cesson-Sevigne Cedex
   France

   Email: Laurent.Toutain@telecom-bretagne.eu


































Minaburo & Toutain      Expires October 21, 2016               [Page 10]