Internet DRAFT - draft-toutain-lp-wan-compression-context
draft-toutain-lp-wan-compression-context
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]
