| 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
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.
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 (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.
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.
[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.
| |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.
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:
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).