< draft-toutain-6lpwa-ipv6-static-context-hc-00.txt		draft-toutain-6lpwa-ipv6-static-context-hc-01.txt >
	Network Working Group A. Minaburo		Network Working Group A. Minaburo
	Internet-Draft Acklio		Internet-Draft Acklio
	Intended status: Informational L. Toutain		Intended status: Informational L. Toutain
	Expires: December 8, 2016 Institut MINES TELECOM ; TELECOM Bretagne		Expires: December 23, 2016 Institut MINES TELECOM ; TELECOM Bretagne
	June 6, 2016		June 21, 2016
	6LPWA Static Context Header Compression (SCHC) for IPV6 and UDP		6LPWA Static Context Header Compression (SCHC) for IPV6 and UDP
	draft-toutain-6lpwa-ipv6-static-context-hc-00		draft-toutain-6lpwa-ipv6-static-context-hc-01
	Abstract		Abstract
	This document describes a header compression scheme for IPv6, IPv6/		This document describes a header compression scheme for IPv6, IPv6/
	UDP based on static contexts. This technique is especially tailored		UDP based on static contexts. This technique is especially tailored
	for LPWA networks and could be extended to other protocol stacks.		for LPWA networks and could be extended to other protocol stacks.
	During the IETF history several compression mechanisms have been		During the IETF history several compression mechanisms have been
	proposed. First mechanisms, such as RoHC, are using a context to		proposed. First mechanisms, such as RoHC, are using a context to
	store header field values and send smaller incremental differences on		store header field values and send smaller incremental differences on
	the link. Values in the context evolve dynamically with information		the link. Values in the context evolve dynamically with information
	contained in the compressed header. The challenge is to maintain		contained in the compressed header. The challenge is to maintain
	sender's and receiver's contexts synchronized even with packet		sender's and receiver's contexts synchronized even with packet
	losses. Based on the fact that IPv6 contains only static fields,		losses. Based on the fact that IPv6 contains only static fields,
	6LoWPAN developed an efficient context-free compression mechanisms,		6LoWPAN developed an efficient context-free compression mechanisms,
	allowing better flexibility and performance.		allowing better flexibility and performance.
	The Static Context Header Compression (SCHC) combines the advantages		The Static Context Header Compression (SCHC) combines the advantages
	of RoHC formal notation, which offers a great level of flexibility in		of RoHC context which offers a great level of flexibility in the
	the processing of fields, and 6LoWPAN behavior to elide fields that		processing of fields, and 6LoWPAN behavior to elide fields that are
	are known from the other side. Static context means that values in		known from the other side. Static context means that values in the
	the context field do not change during the transmission, avoiding		context field do not change during the transmission, avoiding complex
	complex resynchronization mechanisms, incompatible with LPWA		resynchronization mechanisms, incompatible with LPWA characteristics.
	characteristics. In most of the cases, IPv6/UDP/CoAP headers are		In most of the cases, IPv6/UDP headers are reduced to a small
	reduced to a small context identifier.		identifier.
			This document focuses on IPv6/UDP headers compression, but the
			mechanism can be applied to other protocols such as CoAP. It will be
			described in a separate document.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 8, 2016.		This Internet-Draft will expire on December 23, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	1. Introduction		1. Introduction
	Headers compression is mandatory to bring the internet protocols to		Headers compression is mandatory to bring the internet protocols to
	the node within a LPWA network. 6LoWPAN and its evolutions do not		the node within a LPWA network [I-D.minaburo-lp-wan-gap-analysis].
	fulfil the drastic constraints imposed by the radio technology
	[I-D.minaburo-lp-wan-gap-analysis].
	Nevertheless, LPWA networks offer good properties for an efficient		Nevertheless, LPWA networks offer good properties for an efficient
	header compression:		header compression:
	o Topology is star oriented. For the needs of this draft, the		o Topology is star oriented, therefore all the packets follows the
	architecture can be summarized to End-Systems (ES) exchanging		same path. For the needs of this draft, the architecture can be
	information with a single LPWA Compressor (LC). In most of the		summarized to End-Systems (ES) exchanging information with a
	cases, End Systems and LC form a star topology.		single LPWA Compressor (LC). In most of the cases, End Systems
			and LC form a star topology. ESs and LC maintain a context for
			compression.
	o Traffic flows are mostly deterministic, since End-Systems embed		o Traffic flows are mostly deterministic, since End-Systems embed
	built-in applications. Contrary to computers or smartphones, new		built-in applications. Contrary to computers or smartphones, new
	applications cannot be easily installed.		applications cannot be easily installed.
	First mechanisms such as RoHC use a context to store header field		First mechanisms such as RoHC use a context to store header field
	values and send smaller incremental differences on the link. The		values and send smaller incremental differences on the link. The
	first version of RoHC targeted IP/UDP/RTP stack. RoHCv2 extends the		first version of RoHC targeted IP/UDP/RTP stack. RoHCv2 extends the
	principle to any protocol and introduces a formal notation [RFC4997]		principle to any protocol and introduces a formal notation [RFC4997]
	describing the header and associating compression functions to each		describing the header and associating compression functions to each
	skipping to change at page 2, line 50 ¶		skipping to change at page 3, line 4 ¶
	built-in applications. Contrary to computers or smartphones, new		built-in applications. Contrary to computers or smartphones, new
	applications cannot be easily installed.		applications cannot be easily installed.
	First mechanisms such as RoHC use a context to store header field		First mechanisms such as RoHC use a context to store header field
	values and send smaller incremental differences on the link. The		values and send smaller incremental differences on the link. The
	first version of RoHC targeted IP/UDP/RTP stack. RoHCv2 extends the		first version of RoHC targeted IP/UDP/RTP stack. RoHCv2 extends the
	principle to any protocol and introduces a formal notation [RFC4997]		principle to any protocol and introduces a formal notation [RFC4997]
	describing the header and associating compression functions to each		describing the header and associating compression functions to each
	field. To be efficient the sender and the receiver must check that		field. To be efficient the sender and the receiver must check that
	the context remains synchronized (i.e. contains the same values).		the context remains synchronized (i.e. contains the same values).
	Context synchronization imposes to periodically send a full header or		Context synchronization imposes to periodically send a full header or
	at least dynamic fields. If fully compressed, the header can be		at least dynamic fields. If fully compressed, the header can be
	compatible with LPWA constraints. However, the first exchanges or a		compatible with LPWA constraints. However, the first exchanges or
	context resynchronisation impose to send uncompressed headers, which		context resynchronisations impose to send uncompressed headers, which
	may be bigger than the original one. This will force the use of		may be bigger than the original one. This will force the use of
	inefficient fragmentation mechanisms. For some LPWA technologies,		inefficient fragmentation mechanisms. For some LPWA technologies,
	duty cycle limits can also delay the resynchronization. Figure 1		duty cycle limits can also delay the resynchronization. Figure 1
	illustrates this behavior.		illustrates this behavior.
	sync		sync
	^ +-+ sync sync ^		^ +-+ sync sync ^
	| IPv6 | | +-+ +-+ | IPv6		| IPv6 | | +-+ +-+ | IPv6
	v | | | | | | v		v | | | | | | v
	+------------+ | +-+-+ | | | | +------------+		+------------+ | +-+-+ | | | | +------------+
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 32 ¶
	| | x| | +-+-+-+-+-+-+-+-+-+-+-+-+ | | x| |		| | x| | +-+-+-+-+-+-+-+-+-+-+-+-+ | | x| |
	| | t| | <----------------------------> | | t| |		| | t| | <----------------------------> | | t| |
	| +--+ | | +--+ |		| +--+ | | +--+ |
	+------------+ +------------+		+------------+ +------------+
	Figure 1: RoHC Compressed Header size evolution.		Figure 1: RoHC Compressed Header size evolution.
	On the other hand, 6LoWPAN [RFC4944] is context-free based on the		On the other hand, 6LoWPAN [RFC4944] is context-free based on the
	fact that IPv6, its extensions or UDP headers do not contain		fact that IPv6, its extensions or UDP headers do not contain
	incremental fields. The compression mechanism described in [RFC6282]		incremental fields. The compression mechanism described in [RFC6282]
	is based on sending a 2-byte bitmap, which describe how the header		is based on sending a 2-byte bitmap, which describes how the header
	should be decompressed, either using some standard values or		should be decompressed, either using some standard values or sending
	information sent after this bitmap. [RFC6282] also allows for UDP		information after this bitmap. [RFC6282] also allows for UDP
	compression.		compression.
	In the best case, when Hop limit is a standard value, flow label,		In the best case, when Hop limit is a standard value, flow label,
	DiffServ fields are set to 0 and Link Local addresses are used over a		DiffServ fields are set to 0 and Link Local addresses are used over a
	single hop network, the 6LoWPAN compressed header is reduced to 4		single hop network, the 6LoWPAN compressed header is reduced to 4
	bytes. This compression ratio is possible because the IID are		bytes. This compression ratio is possible because the IID are
	derived from the MAC addresses and the link local prefix is known		derived from the MAC addresses and the link local prefix is known
	from both sides. In that case, the IPv6 compression is 4 bytes and		from both sides. In that case, the IPv6 compression is 4 bytes and
	UDP compression is 2 bytes, which fills half of the payload of a		UDP compression is 2 bytes, which fills half of the payload of a
	SIGFOX frame, or more than 10% of a LoRaWAN payload (with spreading		SIGFOX frame, or more than 10% of a LoRaWAN payload (with spreading
	factor 12).		factor 12).
	The Static Context Header Compression (SCHC) combines the advantages		The Static Context Header Compression (SCHC) combines the advantages
	of RoHC formal notation, which offers a great level of flexibility in		of RoHC context, which offers a great level of flexibility in the
	the processing of fields, and 6LoWPAN behavior to elide fields that		processing of fields, and 6LoWPAN behavior to elide fields that are
	are known from the other side. Static context means that values in		known from the other side. Static context means that values in the
	the context field do not change during the transmission, avoiding		context field do not change during the transmission, avoiding complex
	complex resynchronization mechanisms, incompatible with LPWA		resynchronization mechanisms, incompatible with LPWA characteristics.
	characteristics. In most of the cases, IPv6/UDP/CoAP headers are		In most of the cases, IPv6/UDP headers are reduced to a small context
	reduced to a small context identifier.		identifier.
	2. Static Context Header Compression		2. Static Context Header Compression
	Static Context Header Compression (SCHC) avoids context		Static Context Header Compression (SCHC) avoids context
	synchronization, which is the most bandwidth-consuming operation in		synchronization, which is the most bandwidth-consuming operation in
	RoHC. Based on the fact that the nature of data flows is highly		RoHC. Based on the fact that the nature of data flows is highly
	predictable in LPWA networks, a static context may be stored on the		predictable in LPWA networks, a static context may be stored on the
	End-System (ES). The other end, the LPWA Compressor (LC) can learn		End-System (ES). The other end, the LPWA Compressor (LC) can learn
	the context through a provisionning protocol during the		the context through a provisionning protocol during the
	identification phase.		identification phase (for instance, as it learns the encryption key).
	The context contains an ordered lists of rules. Each rule is
	identified by a value, also called context identifier. If the layer
	2 allows it, the context id can be carried in the layer 2 header.
	Otherwise the context id is the first byte of the L2 payload. Being
	at the boundary between Layer 2 and Layer 3, the context id is also
	called a SHIM. Different ES will use the same SHIM to identify their
	own context. An LC needs the ES MAC address to identify the
	appropriate context in its memory.
	Context rules will be used for several purposes:
	o Flow compression: context rules contain a high-level description
	of the headers' fields and associate a function to each of them.
	o Flow decompression: the function associated to each field
	indicates also the decompression behavior.
	o Uncompressed flow selection: The information stored in the context
	rule is also used to match incoming packets to check if the
	compression rule can be applied. There is a strong relation
	between filtering and decompression. For instance, a flow may be
	defined as a set of values that correspond to a set of fields.
	This flow is identified by a SHIM. A destination sharing the same
	context is able to reconstruct the original header upon reception
	of a given SHIM.
	o Compressed flow selection: when receiving a compressed packet,
	information in the context (typically the SHIM) will be used to
	select the decompression rule in combination with the ES MAC
	address.
	o Packet filtering: LPWA can be easily subject to DoS attacks. If a
	packet is not explicitly assigned to a specific context, then
	incoming packets will be discarded.
	3. Filtering functions
	The compression/decompression mechanisms proposed in this Figure 2 is
	a combinaison of 6LoWPAN principles, which are efficient in sending
	only information what cannot be reconstructed at the other end, and
	RoHCv2 which assigns compression and decompression functions to each
	field. The use of a context avoids sending well-known information.
	/--------------------+-----+-----+-------------+--------------------------\
	| Function |Selec|Selec| Compression | Decompression |
	| |comp |dec. | | |
	+--------------------+-----+-----+-------------+--------------------------+
	|ignore |no |no |elided |add value stored in ctxt |
	|send-value |no |no |send value |build field from value |
	|send-value-lbs |yes |no |send lsb |concatenation ctxt val+lsb|
	|send-value-filter |no |yes |send value |elided |
	|not-sent |yes |no |elided |add value stored in ctxt |
	|just-check |yes |yes |nothing |nothing |
	|compute-IPv6-length |no |no |elided |compute IPv6 length |
	|compute-UDP-length |no |no |elided |compute UDP length |
	|compute-UDP-checksum|no |no |elided |compute UDP checksum |
	|ESiid-MAC |no |no |elided |build IID from L2 ES addr |
	|LAiid-MAC |no |no |elided |build IID from L2 LA addr |
	\--------------------+-----+-----+-------------+--------------------------/
	Figure 2: Simplified Protocol Stack for LP-WAN
	Figure 2 lists all the functions defined to compress and decompress a
	field. The first column gives the function's name.
	The second column describes the rule selection property of the
	function. Selection determines if the compression rule can be
	applied to a packet. A comparison is made between the value stored
	in the context and the field's value. Generally it is an equality
	between the field value and a associated context value, but functions
	may define more complex matching rules. To succeed and apply the
	compression/decompression rule, the comparisons of all header fields
	marked as "yes" in this column must be true.
	The third column indicates which function can be used to select the
	appropriate rules for decompression. Typically it will be the SHIM
	and the MAC address.
	Fourth column outlines the compression process.
	Last column outlines the decompression process.
	As with 6LoWPAN, the compression process may produce some data, where		The context contains an ordered list of rules. Each rule is a vector
	fields that were not compressed (or were partially compressed) will		of entries. Each entry is composed of a field descriptor, a
	be sent in the order order of the original packet. Information added		prescribed matching value, a matching rule for the compression side,
	by the compression phase must be aligned on byte boundaries, but each		a matching rule for the decompression side and a compression/
	individual compression function may generate any size.		decompression action. Contexts in the compressor and decompressor
			are the same. A rule is identified by a rule identifier. If the
			layer 2 allows it, the rule id can be carried in the layer 2 header.
			Otherwise the rule id is located in the first byte of the L2 payload.
	/--------------------+---------------------+----------------------------------------\		Being at the boundary between Layer 2 and Layer 3, the rule id will
	| Field |Function | Behavior |		also be called a shim id. Different ES will use the same shim id to
	+--------------------+---------------------+----------------------------------------+		identify their own context. An LC may also use the ES device id to
	|IPv6 version |ignore |No IPv4: not sent, not used for select |		identify the appropriate rule.
	| |send-value-filter* |With IPv4: sent value, used for select |
	+--------------------+---------------------+----------------------------------------+
	|IPv6 DiffServ |not-sent* |The value is not sent, but each end |
	|IPv6 Flow Label | |agree on a value, which can be someting |
	| | |different from 0. |
	| |send-value |If DiffServ field varies it is sent |
	+--------------------+---------------------+----------------------------------------+
	|IPv6 Length |compute-IPv6-length |Dedicated function to reconstruct value |
	+--------------------+---------------------+----------------------------------------+
	[IPv6 Next Header |not-sent* |Value is known in the ctxt. |
	| |send value |Same behavior as 6LoWPAN |
	+--------------------+---------------------+----------------------------------------+
	|IPv6 Hop Limit |ignore |The receiver will put a value stored in |
	| | |the context. It may be different from |
	| | |one originally sent, but in s star |
	| | |topology, there is not risk of loops |
	| |not-sent* |Receiver and sender agree on the value. |
	| | |If the value is not correct the packet |
	| | |is discarded |
	| |send-value |Explicitly sent |
	+--------------------+---------------------+----------------------------------------+
	|IPv6 ESPrefix |not-sent* |The 64 bit prefix is stored on the ctxt |
	|IPv6 LCPrefix |send-value |Explicitly send 64 bits on the link |
	+--------------------+---------------------+----------------------------------------+
	|IPv6 ESiid |not-sent |IID is not sent, but stored in the ctxt |
	|IPv6 LCiid |ESiid-MAC | LCiid-MAC|IID is built from the ES MAC address |
	| |send-value* |IID is explicitly sent on the link. The |
	| | |size depends of the L2 technology |
	+--------------------+---------------------+----------------------------------------+
	|UDP ESport |not-sent |In the context |
	|UDP LCport |send-value* |Send the 2 bytes of the port number |
	| |send-value-lsb* |Send least significant bits of the port |
	| | |number. |
	+--------------------+---------------------+----------------------------------------+
	|UDP length |compute-UDP-length |Dedicated function to reconstruct value |
	|UDP Checksum |compute-UDP-checksum |Dedicated function to reconstruct value |
	+--------------------+---------------------+----------------------------------------+
	* field used for rule selection.
	Figure 3: SCHC functions' example assignment for IPv6 and UDP		+---------------------------------------------------------------------+
			| Rule N |
			+---------------------------------------------------------------------+ |
			| Rule i | |
			+---------------------------------------------------------------------+ | |
			| Rule 1 | | |
			| +---------+-------+------------+--------------+-----------------+ | | |
			| | Field 1 | Value |match. comp.| match decomp | Action function | | | |
			| +---------+-------+------------+--------------+-----------------+ | | |
			| | Field 2 | Value |match. comp.| match decomp | Action function | | | |
			| +---------+-------+------------+--------------+-----------------+ | | |
			| | ... | ... |... | ... | ... | | | |
			| +---------+-------+------------+--------------+-----------------+ | |----+
			| | Field N | Value |match. comp.| match decomp | Action function | | |
			| +---------+-------+------------+--------------+-----------------+ |------+
			| |
			+---------------------------------------------------------------------+
	Figure 3 gives an example of function assignment to IPv6/UDP fields,		Figure 2: Context in LC
	a star after the function name indicates when a field participates in
	the context id selection.
	3.1. Compression functions		The compression/decompression process follows several steps:
	3.1.1. Ignore		o compression rule selection: the goal is to identify which rule
			will be used to compress the headers. To each field is associated
			a matching rule for compression. Each header field's value is
			compared to the corresponding value stored in the rule for that
			field using the matching operator. If all the fields match, the
			packet is processed using this rule action functions and the rule
			list exploration is aborted. Otherwise the next rule is tested.
			If no rule is found, then the packet is dropped.
	Ignore function defines a field that does not participate to the rule		o compression: the action function indicates is the field is send on
	selection process. The field value will not be sent on the wire and		the link or not. A field can also be partially sent regarding the
	can be reconstructed on the other side.		matching operator. The resulting compressed header must be
			aligned on byte boundaries.
	The ignore function can be assigned to the IPv6 version field (if		o decompression rule selection, as for compression, a rule has to be
	IPv4 is not used in the system). IPv6 Hop Limit may also be a		selected to uncompress incoming packets. A matching operator is
	candidate in some cases. Hop Limit value will not affect the flow		defined on the compress header and works as for compression.
	selection process. The receiver may assign a static value. If there
	is a risk of loop creation (i.e. non-star topology), the send-value
	function must be used instead.
	3.1.2. Send-value		o decompression: the same action function indicates how the field
			value can be rebuilt, either from bits received on the link, a
			value stored in the rule or by using a specific algorithm.
	This function is used to transmit the full field value that is not		3. Matching operators
	stored in the context. In the decompression phase, the receiver uses
	the transmitted value for reconstructing the field. This field
	cannot participate to the selection process since it can vary other
	the time.
	The send-value function may be used to send interface IID in a meshed		Matching a field with a value and header compression are related
	topology.		operations; If a field matches a rule containing the value, it is not
			necessary to send it on the link. Since context are synchronized,
			reading the rule's value is enough to reconstruct the field's value
			at the other end.
	3.1.3. Send-value-lsb		On some other cases, the value need to be sent on the link to inform
			the other end. The field value may vary from one packet to another,
			therefore the field cannot be used to select the rule id.
	This function allows to send only the less significant bits of a		It may exist some intermediary cases, where part of the value may be
	value. The context contains the size of the less significant bits		used to select a field and a variable part has to be sent on the
	and a reference value.		link. This is true for Least Significant Bits (LSB) where the most
			significant bit can be used to select a rule id and the least
			significant bits has to be sent on the link.
	Send-value-lbs is involved in the rule selection. The most		Several matching operators are defined:
	significant bit of field's value must matches the most significant
	bits of the context reference value.
	The sender send on the radio link only the less significant bits.		o = : a field value in a packet matches with a field value in a rule
	The receiver reconstruct the initial value by concatenating the most		if they are equal.
	significant bits of reference value contained in the context and the
	less significant bits received.
	This function can be used to define a port range and allow several IP		o no : no check is done between a field value in a packet matches
	flows to share the same context.		with a field value in the rule
	3.1.4. Send-value-filter		o lbs(L) : a field value of length T in a packet matches with a
			field value in a rule if the most significant T-L bits are equal.
	In the compression phase, a field assigned with this value is sent on		4. Action functions
	the radio link. It does not influence the rule selection.
	Value sent on the link influences the rule selection for		The action functions describe the action taken by the compression and
	decompression.		inversely the action taken by the decompressor to restore the
			original value.
	Typically, this function is used to transmit the SHIM field and		/--------------------+-------------+--------------------------\
	proceed to rule identification when the header is decompressed. The		| Function | Compression | Decompression |
	SHIM is elided from the uncompressed header.		| | | |
			+--------------------+-------------+--------------------------+
			|elided |not sent |use value stored in ctxt |
			|send-value |send |build field from value |
			|compute-IPv6-length |elided |compute IPv6 length |
			|compute-UDP-length |elided |compute UDP length |
			|compute-UDP-checksum|elided |compute UDP checksum |
			|ESiid-DID |elided |build IID from L2 ES addr |
			|LCiid-DID |elided |build IID from L2 LA addr |
			\--------------------+-------------+--------------------------/
	3.1.5. Not-sent		Figure 3: Simplified Protocol Stack for LP-WAN
	In the compression phase, a field assigned with this value is not		Figure 3 lists all the functions defined to compress and decompress a
	sent on the radio link. This influence the rule selection.		field. The first column gives the function's name. The second and
			third columns outlines the compression/decompression process.
	In the decompression phase, the uncompressed value is the one stored		As with 6LoWPAN, the compression process may produce some data, where
	in the context. Since the value is not send on the radio link, it		fields that were not compressed (or were partially compressed) will
	cannot influence the flow selection.		be sent in the order of the original packet. Information added by
			the compression phase must be aligned on byte boundaries, but each
			individual compression function may generate any size.
	IPv6 protocol identifier, UDP ports number fields can be assigned to		/-----------------+---------------------+----------------------------------------\
	this function. This avoid to send then on the link.		| Field |Function | Behavior |
			+-----------------+---------------------+----------------------------------------+
			|IPv6 version |elided |The value is not sent, but each end |
			|IPv6 DiffServ | |agrees on a value, which can be |
			|IPv6 Flow Label | |different from 0. |
			|IPv6 Next Header |send-value |Depending on the matching operator, the |
			| | |entire field value is sent or an |
			| | |adjustment to the context value |
			+-----------------+---------------------+----------------------------------------+
			|IPv6 Length |compute-IPv6-length |Dedicated function to reconstruct value |
			+-----------------+---------------------+----------------------------------------+
			|IPv6 Hop Limit |elided+no matching |The receiver will put a value stored in |
			| | |the context. It may be different from |
			| | |one originally sent, but in a star |
			| | |topology, there is not risk of loops |
			| |elided+matching |Receiver and sender agree on the value. |
			| | |If the value is not correct the packet |
			| | |the rule is not selected |
			| |send-value |Explicitly sent |
			+-----------------+---------------------+----------------------------------------+
			|IPv6 ESPrefix |elided |The 64 bit prefix is stored on the ctxt |
			|IPv6 LCPrefix |send-value |Explicitly send 64 bits on the link |
			+-----------------+---------------------+----------------------------------------+
			|IPv6 ESiid |elided |IID is not sent, but stored in the ctxt |
			|IPv6 LCiid |ESiid-DID | LCiid-DID|IID is built from the ES Device ID |
			| |send-value |IID is explicitly sent on the link. The |
			| | |size depends of the L2 technology |
			+-----------------+---------------------+----------------------------------------+
			|UDP ESport |elided |In the context |
			|UDP LCport |send-value |Send the 2 bytes of the port number |
			| | |or less if lsb matching is specified in |
			| | |the matching operator. |
			+-----------------+---------------------+----------------------------------------+
			|UDP length |compute-UDP-length |Dedicated function to reconstruct value |
			+-----------------+---------------------+----------------------------------------+
			|UDP Checksum |compute-UDP-checksum |Dedicated function to reconstruct value |
			+-----------------+---------------------+----------------------------------------+
	3.1.6. just-check		Figure 4: SCHC functions' example assignment for IPv6 and UDP
	The field value is checked for the rule selection, but nothing is		Figure 4 gives an example of function assignment to IPv6/UDP fields.
	sent on the radio link.
	This can be used to include L2 parameters such as addresses in the		4.1. Action functions
	rule selection.		4.1.1. Elided
	3.1.7. compute-IPv6-lenght, compute-UDP-length, compute-UDP-checksum		The compressor do not sent the field value on the link. The
			decompressor restore the field value with the one stored in the
			matched rule.
	Fields assigned with this functions are not sent on the radio link,		4.1.2. Send-value
	they do not participate to the rule selection process. They are
	computed during the decompression phase.
	This functions are specific to a field in the header.		The compressor send the field value on the link, if the matching
			operator is "=". Otherwise the matching operator indicates the
			information that will be sent on the link. For a LSB operator only
			the Least Significant Bits are sent.
	3.1.8. ESiid-MAC, LCiid-MAC		4.1.3. ESiid-DID, LCiid-DID
	These functions are used to process respectively the End System and		These functions are used to process respectively the End System and
	the LPWA AP Interface Identifier. The IID value is computed from		the LC Device Identifier (DID). The IID value is computed from
	addresses present in the MAC header. The computation depends of the		device ID present in the Layer 2 header. The computation depends of
	technology and the MAC address size. The values of the field do not		the technology and the device ID size.
	participate to the flow selection since they are sent on the radio
	link at layer 2.
	These functions can be used in case of the star topology.
	4. Examples		5. Examples
	This section gives some scenarios of the compression mechanism. Note		This section gives some scenarios of the compression mechanism for
	that for reasons of simplicity in this example CoAP is not		IPv6/UDP. The goal is to illustrate the SCHC behaviour.
	compressed, it will be described later with the same principles. The
	goal is to illustrate the SCHC behaviour.
	4.1. IPv6/UDP compression in a star topology		5.1. IPv6/UDP compression in a star topology
	The most common case will be a LPWA end-system embeds some		The most common case will be a LPWA end-system embeds some
	applications running over CoAP. Typically one will be for the device		applications running over CoAP. In this example, the first flow is
	management using the COMI/CoOL protocol (using UDP ports 123 and		for instance for the device management based on CoAP using Link Local
	124). The second one will be a CoAP server for measurements done by		addresses and UDP ports 123 and 124. The second flow will be a CoAP
	the end-system (using ports 5683). A third UDP traffic is for legacy		server for measurements done by the end-system (using ports 5683) and
	applications using different ports numbers. Figure 4 presents the		Global Addresses alpha::IID/64 to beta::1/64. The last flow is for
	protocol stack for this end-system. IPv6 and UDP are represented		legacy applications using different ports numbers, the destination is
	with dotted lines since these protocols are compressed on the radio		gamma::1/64.
	link. The context ID is represented by a SHIM (respectively 0, 1 and
	2).
	|		Figure 5 presents the protocol stack for this end-system. IPv6 and
	|/c |/a |		UDP are represented with dotted lines since these protocols are
			compressed on the radio link. The rule ID is represented by a shim
			id (respectively 0, 1 and 2).
			Managment Data
	+----------+---------+---------+		+----------+---------+---------+
	| CoAP | CoAP | legacy |		| CoAP | CoAP | legacy |
	+----||----+---||----+---||----+		+----||----+---||----+---||----+
	. UDP . UDP | UDP |		. UDP . UDP | UDP |
	................................		................................
	. IPv6 . IPv6 . IPv6 .		. IPv6 . IPv6 . IPv6 .
	+--SHIM0------SHIM1-----SHIM2---------------------------+		+--SHIM0------SHIM1-----SHIM2--+
	| 6LPWA L2 technologies |		| 6LPWA L2 technologies |
	+-------------------------------------------------------+		+------------------------------+
	End System or LPWA GW		End System or LPWA GW
	Figure 4: Simplified Protocol Stack for LP-WAN
	Note that in some LPWA technologies, only End Systems have a MAC
	address. Therefore it is necessary to define an IID for the Link
	Local address for the LPWA Compressor.
	+----------------+------------------------+----------------+-----------------+
	| Field | Function | Ctxt Value | Sent compressed |
	+----------------+------------------------+----------------+-----------------+
	| LPWA SHIM | send-value-filter | 0 | 0 |
	+================+========================+================+=================+
	|IPv6 version | ignore | | |
	|IPv6 DiffServ | not-sent | 0 | |
	|IPv6 Flow Label | not-sent | 0 | |
	|IPv6 Length | compute-IPv6-length |----------------| |
	|IPv6 Next Header| not-sent | 17 | |
	|IPv6 Hop Limit | ignore | 1 | |
	|IPv6 ESprefix | not-sent | FE80::/64 | |
	|IPv6 ESiid | ESiid-MAC | | |
	|IPv6 LCprefix | not-sent | FE80::/64 | |
	|IPv6 LCiid | LCiid-value | ::1 | |
	+================+========================+================+=================+
	|UDP ESport | not-sent | 123 | |
	|UDP LCport | not-sent | 124 | |
	|UDP Length | compute-UDP-length |----------------| |
	|UDP checksum | compute-UDP-checksum |----------------| |
	+================+========================+================+=================+
	+----------------+------------------------+----------------+-----------------+
	| Field | Function | Ctxt Value | Sent compressed |
	+----------------+------------------------+----------------+-----------------+
	| LPWA SHIM | send-value-filter | 1 | 1 |
	+================+========================+================+=================+
	|IPv6 version | ignore | | |
	|IPv6 DiffServ | not-sent | 0 | |
	|IPv6 Flow Label | not-sent | 0 | |
	|IPv6 Length | compute-IPv6-length |----------------| |
	|IPv6 Next Header| not-sent | 17 | |
	|IPv6 Hop Limit | ignore | 1 | |
	|IPv6 ESprefix | not-sent | FE80::/64 | |
	|IPv6 ESiid | ESiid-MAC | | |
	|IPv6 LCprefix | not-sent | FE80::/64 | |
	|IPv6 LCiid | LCiid-value | ::1 | |
	+================+========================+================+=================+
	|UDP ESport | not-sent | 5683 | |
	|UDP LCport | not-sent | 5683 | |
	|UDP Length | compute-UDP-length |----------------| |
	|UDP checksum | compute-UDP-checksum |----------------| |
	+================+========================+================+=================+
	+----------------+------------------------+----------------+-----------------+
	| Field | Function | Ctxt Value | Sent compressed |
	+----------------+------------------------+----------------+-----------------+
	| LPWA SHIM | send-value-filter | 2 | 2 |
	+================+========================+================+=================+
	|IPv6 version | ignore | | |
	|IPv6 DiffServ | not-sent | 0 | |
	|IPv6 Flow Label | not-sent | 0 | |
	|IPv6 Length | compute-IPv6-length |----------------| |
	|IPv6 Next Header| not-sent | 17 | |
	|IPv6 Hop Limit | ignore | 1 | |
	|IPv6 ESprefix | not-sent | FE80::/64 | |
	|IPv6 ESiid | ESiid-MAC | | |
	|IPv6 LCprefix | not-sent | FE80::/64 | |
	|IPv6 LCiid | LCiid-value | ::1 | |
	+================+========================+================+=================+
	|UDP ESport | send-value | | port number |
	|UDP LCport | send-value | | port number |
	|UDP Length | compute-UDP-length |----------------| |
	|UDP checksum | compute-UDP-checksum |----------------| |
	+================+========================+================+=================+
	Figure 5: Simplified Protocol Stack for LP-WAN		Figure 5: Simplified Protocol Stack for LP-WAN
	Figure 6 shows an alternative way to compress more efficiently port		Note that in some LPWA technologies, only End Systems have a device
	numbers. The send-value-lsb allows to send in one byte the two ports		ID . Therefore it is necessary to define statically an IID for the
	number differences. Since the compressed information must be aligned		Link Local address for the LPWA Compressor.
	on byte boundary, it has been chosen in the example a size of 4 bits
	for each lsb.
	+----------------+------------------------+----------------+-----------------+
	| Field | Function | Ctxt Value | Sent compressed |
	+----------------+------------------------+----------------+-----------------+
	| LPWA SHIM | send-value-filter | 2 | 2 |
	+================+========================+================+=================+
	|IPv6 version | ignore | | |
	|IPv6 DiffServ | not-sent | 0 | |
	|IPv6 Flow Label | not-sent | 0 | |
	|IPv6 Length | compute-IPv6-length |----------------| |
	|IPv6 Next Header| not-sent | 17 | |
	|IPv6 Hop Limit | ignore | 1 | |
	|IPv6 ESprefix | not-sent | FE80::/64 | |
	|IPv6 ESiid | ESiid-MAC | | |
	|IPv6 LCprefix | not-sent | FE80::/64 | |
	|IPv6 LCiid | LCiid-value | ::1 | |
	+================+========================+================+=================+
	|UDP ESport | send-value-lsb | 4+ES ref val | lsb |
	|UDP LCport | send-value-lsb | 4+LC ref val | lsb |
	|UDP Length | compute-UDP-length |----------------| |
	|UDP checksum | compute-UDP-checksum |----------------| |
	+================+========================+================+=================+
	Figure 6: Alternative compressions of port numbers		+----------------+---------+--------+--------+-------------++------+
			| Field | Value | Match | Match | Function || Sent |
			+----------------+---------+-----------------+-------------++------+
			|LPWA SHIM |0 | No | = | send-value || 0 |
			|ESDevice-ID |dev-id | No | = | elided || |
			+================+=========+========+========+=============++======+
			|IPv6 version |6 | = | No | elided || |
			|IPv6 DiffServ |0 | = | No | elided || |
			|IPv6 Flow Label |0 | = | No | elided || |
			|IPv6 Length |XXXXXXXXX| No | No | comp-IPv6-l || |
			|IPv6 Next Header|17 | = | No | elided || |
			|IPv6 Hop Limit |255 | No | No | elided || |
			|IPv6 ESprefix |FE80::/64| = | No | elided || |
			|IPv6 ESiid | | No | No | ESiid-DID || |
			|IPv6 LCprefix |FE80::/64| = | No | elided || |
			|IPv6 LCiid |::1 | = | No | elided || |
			+================+=========+========+========+=============++======+
			|UDP ESport |123 | = | No | elided || |
			|UDP LCport |124 | = | No | elided || |
			|UDP Length |XXXXXXXXX| No | No | comp-UDP-l || |
			|UDP checksum |XXXXXXXXX| No | No | comp-UDP-c || |
			+================+=========+========+========+=============++======+
	4.2. Global addresses		+----------------+---------+--------+--------+-------------++------+
			| Field | Value | Match | Match | Function || Sent |
			+----------------+---------+-----------------+-------------++------+
			|LPWA SHIM |1 | No | = | send-value || 1 |
			|ESDevice-ID |dev-id | No | = | elided || |
			+================+=========+========+========+=============++======+
			|IPv6 version |6 | = | No | elided || |
			|IPv6 DiffServ |0 | = | No | elided || |
			|IPv6 Flow Label |0 | = | No | elided || |
			|IPv6 Length |XXXXXXXXX| No | No | comp-IPv6-l || |
			|IPv6 Next Header|17 | = | No | elided || |
			|IPv6 Hop Limit |255 | No | No | elided || |
			|IPv6 ESprefix |alpha/64 | = | No | elided || |
			|IPv6 ESiid | | No | No | ESiid-DID || |
			|IPv6 LCprefix |beta/64 | = | No | elided || |
			|IPv6 LCiid |::1000 | = | No | elided || |
			+================+=========+========+========+=============++======+
			|UDP ESport |5683 | = | No | elided || |
			|UDP LCport |5683 | = | No | elided || |
			|UDP Length |XXXXXXXXX| No | No | comp-UDP-l || |
			|UDP checksum |XXXXXXXXX| No | No | comp-UDP-c || |
			+================+=========+========+========+=============++======+
	The scenario depicted Figure 7, management remains with Link Local		+----------------+---------+--------+--------+-------------++------+
	addresses, but the CoAP message are sent to an external server		| Field | Value | Match | Match | Function || Sent |
	2001:db8:1::1 and the legacy to another server 2001:db8:2::1/64. The		+----------------+---------+-----------------+-------------++------+
	EC must be configured with the prefix used by the LC to forward		|LPWA SHIM |2 | No | = | send-value || 2 |
	traffic. This prefix could be changed using a management procedure		|ESDevice-ID |dev-id | No | = | elided || |
	if needed.		+================+=========+========+========+=============++======+
			|IPv6 version |6 | = | No | elided || |
			|IPv6 DiffServ |0 | = | No | elided || |
			|IPv6 Flow Label |0 | = | No | elided || |
			|IPv6 Length |XXXXXXXXX| No | No | comp-IPv6-l || |
			|IPv6 Next Header|17 | = | No | elided || |
			|IPv6 Hop Limit |255 | No | No | elided || |
			|IPv6 ESprefix |alpha/64 | = | No | elided || |
			|IPv6 ESiid | | No | No | ESiid-DID || |
			|IPv6 LCprefix |gamma/64 | = | No | elided || |
			|IPv6 LCiid |::1000 | = | No | elided || |
			+================+=========+========+========+=============++======+
			|UDP ESport |8720 | lsb(4) | No | elided || lsb |
			|UDP LCport |8720 | lsb(4) | No | elided || lsb |
			|UDP Length |XXXXXXXXX| No | No | comp-UDP-l || |
			|UDP checksum |XXXXXXXXX| No | No | comp-UDP-c || |
			+================+=========+========+========+=============++======+
	+----------------+------------------------+----------------+-----------------+		Figure 6: Simplified Protocol Stack for LP-WAN
	| Field | Function | Ctxt Value | Sent compressed |
	+----------------+------------------------+----------------+-----------------+
	| LPWA SHIM | send-value-filter | 0 | 0 |
	+================+========================+================+=================+
	|IPv6 version | ignore | | |
	|IPv6 DiffServ | not-sent | 0 | |
	|IPv6 Flow Label | not-sent | 0 | |
	|IPv6 Length | compute-IPv6-length |----------------| |
	|IPv6 Next Header| not-sent | 17 | |
	|IPv6 Hop Limit | ignore | 1 | |
	|IPv6 ESprefix | not-sent | FE80::/64 | |
	|IPv6 ESiid | ESiid-MAC | | |
	|IPv6 LCprefix | not-sent | FE80::/64 | |
	|IPv6 LCiid | LCiid-value | ::1 | |
	+================+========================+================+=================+
	|UDP ESport | not-sent | 123 | |
	|UDP LCport | not-sent | 124 | |
	|UDP Length | compute-UDP-length |----------------| |
	|UDP checksum | compute-UDP-checksum |----------------| |
	+================+========================+================+=================+
	+----------------+------------------------+----------------+-----------------+		All the fields described in the three rules Figure 6 are present in
	| Field | Function | Ctxt Value | Sent compressed |		the IPv6 and UDP headers. Two fields have been added at the begin,
	+----------------+------------------------+----------------+-----------------+		they are used to identify the rule id for decompression when the
	| LPWA SHIM | send-value-filter | 1 | 1 |		other end receives the compressed header. The shim id is read either
	+================+========================+================+=================+		from the L2 header or from the first bit in the payload depending on
	|IPv6 version | ignore | | |		the technology. The ESDevice-ID value is found in the L2 header.
	|IPv6 DiffServ | not-sent | 0 | |
	|IPv6 Flow Label | not-sent | 0 | |
	|IPv6 Length | compute-IPv6-length |----------------| |
	|IPv6 Next Header| not-sent | 17 | |
	|IPv6 Hop Limit | ignore | 1 | |
	|IPv6 ESprefix | not-sent |2001:db8:3::/64 | |
	|IPv6 ESiid | ESiid-MAC | | |
	|IPv6 LCprefix | not-sent |2001:bd8:1::/64 | |
	|IPv6 LCiid | LCiid-value | ::1 | |
	+================+========================+================+=================+
	|UDP ESport | not-sent | 5683 | |
	|UDP LCport | not-sent | 5683 | |
	|UDP Length | compute-UDP-length |----------------| |
	|UDP checksum | compute-UDP-checksum |----------------| |
	+================+========================+================+=================+
	+----------------+------------------------+----------------+-----------------+		The second and third rules use global addresses. The way the ES
	| Field | Function | Ctxt Value | Sent compressed |		learn the prefix is not in the scope of the document. One possible
	+----------------+------------------------+----------------+-----------------+		way is to use a management protocol to set up in both end rules the
	| LPWA SHIM | send-value-filter | 2 | 2 |		prefix used on the LPWA network.
	+================+========================+================+=================+
	|IPv6 version | ignore | | |
	|IPv6 DiffServ | not-sent | 0 | |
	|IPv6 Flow Label | not-sent | 0 | |
	|IPv6 Length | compute-IPv6-length |----------------| |
	|IPv6 Next Header| not-sent | 17 | |
	|IPv6 Hop Limit | ignore | 1 | |
	|IPv6 ESprefix | not-sent |2001:db8:3::/64 | |
	|IPv6 ESiid | ESiid-MAC | | |
	|IPv6 LCprefix | not-sent |2001:db8:2::/64 | |
	|IPv6 LCiid | LCiid-value | ::1 | |
	+================+========================+================+=================+
	|UDP ESport | send-value | | port number |
	|UDP LCport | send-value | | port number |
	|UDP Length | compute-UDP-length |----------------| |
	|UDP checksum | compute-UDP-checksum |----------------| |
	+================+========================+================+=================+
	Figure 7: Compression with global addresses		The third rule compresses port numbers on 4 bits. This value is
			selected to maintain alignment on byte boundaries for the compressed
			header.
	5. CoAP compression		6. Acknowledgements
	TBD		Thanks to Dominique Barthel, Alexander Pelov, Juan Carlos Zuniga for
			useful design consideration.
	6. Normative References		7. Normative References
	[I-D.minaburo-lp-wan-gap-analysis]		[I-D.minaburo-lp-wan-gap-analysis]
	Minaburo, A., Pelov, A., and L. Toutain, "LP-WAN GAP		Minaburo, A., Pelov, A., and L. Toutain, "LP-WAN GAP
	Analysis", draft-minaburo-lp-wan-gap-analysis-01 (work in		Analysis", draft-minaburo-lp-wan-gap-analysis-01 (work in
	progress), February 2016.		progress), February 2016.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4		"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,		Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
	<http://www.rfc-editor.org/info/rfc4944>.		<http://www.rfc-editor.org/info/rfc4944>.
End of changes. 61 change blocks.
	424 lines changed or deleted		292 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/