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

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

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

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

The example continues with a effective compression.

  • 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.
  • 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.
  • lsb allows to send in few bits a small modification in the field value.

3. Compression of IPv6 and UDP

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

Figure 4: Simplified Protocol Stack for LP-WAN

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

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. Figure 5 describes the definition of the IPv6/UDP protocol stack based on [RFC5225]. [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.

  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

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.

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

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

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

The IPv6/UDP stack can be represented like this:

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. Normative References

[I-D.minaburo-lp-wan-gap-analysis] Minaburo, A., Pelov, A. and L. Toutain, "LP-WAN GAP Analysis", Internet-Draft draft-minaburo-lp-wan-gap-analysis-01, 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.
[RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust Header Compression (ROHC-FN)", RFC 4997, DOI 10.17487/RFC4997, July 2007.
[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.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011.

Authors' Addresses

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

Table of Contents