One document matched: draft-toutain-lp-wan-compression-context-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc3095 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3095.xml'>
<!ENTITY rfc5225 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5225.xml'>
<!ENTITY rfc4997 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4997.xml'>
<!ENTITY rfc6282 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml'>
<!ENTITY gapAna PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-minaburo-lp-wan-gap-analysis-01.xml'>
]>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<rfc category="info" docName="draft-toutain-lp-wan-compression-context-00" ipr="trust200902">
<front>
<title abbrev="LP-WAN Compression Context">LP-WAN Compression Context</title>
<author fullname="Ana Minaburo" initials="A." surname="Minaburo">
<organization>Acklio</organization>
<address>
<postal>
<street>2bis rue de la Chataigneraie</street>
<city>35510 Cesson-Sevigne Cedex</city>
<country>France</country>
</postal>
<email>ana@ackl.io</email>
</address>
</author>
<author fullname="Laurent Toutain" initials="L." surname="Toutain">
<organization>Institut MINES TELECOM ; TELECOM Bretagne</organization>
<address>
<postal>
<street>2 rue de la Chataigneraie</street>
<street>CS 17607</street>
<city>35576 Cesson-Sevigne Cedex</city>
<country>France</country>
</postal>
<email>Laurent.Toutain@telecom-bretagne.eu</email>
</address>
</author>
<date month="April" year="2016" />
<!-- <workgroup>v6ops Working Group </workgroup> -->
<abstract>
<t>
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
<xref target='RFC4997'/> may be written in CBOR or YANG.
</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>
Robust Header Compression (RoHC) <xref target='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) <xref target='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.
<eref target="http://dl.acm.org/citation.cfm?id=2728090">This document</eref> gives an
overview of RoHC behavior.
</t>
<t>
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
<xref target="I-D.minaburo-lp-wan-gap-analysis" /> . It is also necessary to simplify several notation and
avoid a specific notation. Concept described in <xref target='RFC4997'/> may be
written in CBOR or YANG.
</t>
</section>
<section anchor="FN" title="Formal Notation">
<t>
<xref target='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.
</t>
<t>
<figure anchor="fig-ex1"
title="Simplest header representation"><artwork><![CDATA[
eg_header
{
UNCOMPRESSED {
field_1 [ 2 ];
}
COMPRESSED initial_definition {
field_1 =:= fct(x);
}
}
]]></artwork></figure>
<xref target="fig-ex1" /> 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.
</t>
<t>
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).
</t>
<t>
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.
</t>
<t>
<figure anchor="fig-ex2"
title="Null compression"><artwork><![CDATA[
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);
}
}
]]></artwork></figure>
This example, taken from <xref target='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.
</t>
<t>
The example continues with a effective compression.
<figure anchor="fig-ex3"
title="Header compression"><artwork><![CDATA[
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);
}
}
]]></artwork></figure>
Several functions are called:
<list style="symbols">
<t>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.</t>
<t>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. </t>
<t> lsb allows to send in few bits a small modification in the field value.</t>
</list>
</t>
</section>
<section anchor="compressIPv6" title="Compression of IPv6 and UDP">
<t>
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,
<xref target="FigStack" /> 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 anchor="FigStack"
title="Simplified Protocol Stack for LP-WAN"><artwork><![CDATA[
|
|auth|cool |
+----------+---------+
| CoAP | CoAP |
+....||....+...||....+
: UDP : UDP :
:..........:.........:
: 6LP : 6LP :
+-------------------------------------------------------+
| SHIM |
+-------------------------------------------------------+
| LP-WAN L2 technologies |
+-------------------------------------------------------+
]]></artwork></figure>
<xref target="fig-ex4"/> describes the definition of the IPv6/UDP protocol stack
based on <xref target="RFC5225"/>.
<figure anchor="fig-ex4"
title="IPv6/UDP header description"><artwork><![CDATA[
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 ];
}
]]></artwork></figure>
The main difference is the split in two fields of the source and destination
address to be closer to 6LoWPAN <xref target="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.
</t>
<t>
<figure anchor="fig-ex5"
title="IPv6/UDP compression to a shim"><artwork><![CDATA[
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]
}
]]></artwork></figure>
The compression methods are defined <xref target="fig-ex3"/>. 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.
</t>
<t> 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.
</t>
</section>
<section anchor="CBOR" title="6WIDe representation">
<t>
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 <xref target="compressIPv6"/>. This also can derive from a Yang model.
</t>
<t>
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.
</t>
<t>
<figure anchor="fig-ex6"
title="CBOR framework"><artwork><![CDATA[
[ // 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
]]></artwork></figure>
</t>
<t>
The IPv6/UDP stack can be represented like this:
<figure anchor="fig-ex7"
title="CBOR framework"><artwork><![CDATA[
[ // 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
]
]]></artwork></figure>
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.
<figure anchor="fig-ex8"
title="CBOR framework"><artwork><![CDATA[
[ // first compressed format
[ // predicates
[4, 17], // NH == 17
[11, 123] // src port == 123
[12, 124] // dst port == 124
]
[
[-8, [0, 8, 0]] // SHIM 0
]
]
]
]]></artwork></figure>
-8 state for the creation of a new field of 8 bits in the compress format. Function 0 set the
value to 0.
</t>
</section>
<section anchor="CoAP" title="CoAP compression">
<t>
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).
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc3095;
&rfc4997;
&rfc5225;
&rfc6282;
&gapAna;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:25:37 |