< draft-ietf-lpwan-ipv6-static-context-hc-02.txt		draft-ietf-lpwan-ipv6-static-context-hc-03.txt >
	lpwan Working Group A. Minaburo		lpwan Working Group A. Minaburo
	Internet-Draft Acklio		Internet-Draft Acklio
	Intended status: Informational L. Toutain		Intended status: Informational L. Toutain
	Expires: September 11, 2017 IMT-Atlantique		Expires: November 6, 2017 IMT-Atlantique
	C. Gomez		C. Gomez
	Universitat Politecnica de Catalunya		Universitat Politecnica de Catalunya
	March 10, 2017		May 05, 2017
	LPWAN Static Context Header Compression (SCHC) and fragmentation for		LPWAN Static Context Header Compression (SCHC) and fragmentation for
	IPv6 and UDP		IPv6 and UDP
	draft-ietf-lpwan-ipv6-static-context-hc-02		draft-ietf-lpwan-ipv6-static-context-hc-03
	Abstract		Abstract
	This document describes a header compression scheme and fragmentation		This document describes a header compression scheme and fragmentation
	functionality for IPv6/UDP protocols. These techniques are		functionality for IPv6/UDP protocols. These techniques are
	especially tailored for LPWAN (Low Power Wide Area Network) networks		especially tailored for LPWAN (Low Power Wide Area Network) networks
	and could be extended to other protocol stacks.		and could be extended to other protocol stacks.
	The Static Context Header Compression (SCHC) offers a great level of		The Static Context Header Compression (SCHC) offers a great level of
	flexibility when processing the header fields. Static context means		flexibility when processing the header fields. Static context means
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 September 11, 2017.		This Internet-Draft will expire on November 6, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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.
			Table of Contents
			1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
			2. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . 4
			3. Static Context Header Compression . . . . . . . . . . . . . . 5
			3.1. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . 7
			3.2. Packet processing . . . . . . . . . . . . . . . . . . . . 7
			4. Matching operators . . . . . . . . . . . . . . . . . . . . . 8
			5. Compression Decompression Actions (CDA) . . . . . . . . . . . 9
			5.1. not-sent CDA . . . . . . . . . . . . . . . . . . . . . . 10
			5.2. value-sent CDA . . . . . . . . . . . . . . . . . . . . . 10
			5.3. mapping-sent . . . . . . . . . . . . . . . . . . . . . . 10
			5.4. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . . . 10
			5.5. DEViid-DID, APPiid-DID CDA . . . . . . . . . . . . . . . 11
			5.6. Compute-* . . . . . . . . . . . . . . . . . . . . . . . . 11
			6. Application to IPv6 and UDP headers . . . . . . . . . . . . . 11
			6.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 11
			6.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 12
			6.3. Flow label field . . . . . . . . . . . . . . . . . . . . 12
			6.4. Payload Length field . . . . . . . . . . . . . . . . . . 12
			6.5. Next Header field . . . . . . . . . . . . . . . . . . . . 13
			6.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . . 13
			6.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . . 13
			6.7.1. IPv6 source and destination prefixes . . . . . . . . 13
			6.7.2. IPv6 source and destination IID . . . . . . . . . . . 14
			6.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . . 14
			6.9. UDP source and destination port . . . . . . . . . . . . . 15
			6.10. UDP length field . . . . . . . . . . . . . . . . . . . . 15
			6.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 15
			7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
			7.1. IPv6/UDP compression . . . . . . . . . . . . . . . . . . 16
			8. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 18
			8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18
			8.2. Reliability options: definition . . . . . . . . . . . . . 19
			8.3. Reliability options: discussion . . . . . . . . . . . . . 20
			8.4. Fragment format . . . . . . . . . . . . . . . . . . . . . 21
			8.5. Fragmentation header formats . . . . . . . . . . . . . . 22
			8.6. ACK format . . . . . . . . . . . . . . . . . . . . . . . 24
			8.7. Baseline mechanism . . . . . . . . . . . . . . . . . . . 25
			8.8. Aborting a fragmented IPv6 datagram transmission . . . . 28
			8.9. Downlink fragment transmission . . . . . . . . . . . . . 28
			9. Security considerations . . . . . . . . . . . . . . . . . . . 29
			9.1. Security considerations for header compression . . . . . 29
			9.2. Security considerations for fragmentation . . . . . . . . 29
			10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
			11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
			11.1. Normative References . . . . . . . . . . . . . . . . . . 30
			11.2. Informative References . . . . . . . . . . . . . . . . . 30
			Appendix A. Fragmentation examples . . . . . . . . . . . . . . . 30
			Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 35
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
	1. Introduction		1. Introduction
	Header compression is mandatory to efficiently bring Internet		Header compression is mandatory to efficiently bring Internet
	connectivity to the node within a LPWAN network		connectivity to the node within a LPWAN network
	[I-D.minaburo-lp-wan-gap-analysis].		[I-D.minaburo-lp-wan-gap-analysis].
	Some LPWAN networks properties can be exploited for an efficient		Some LPWAN networks properties can be exploited for an efficient
	header compression:		header compression:
	o Topology is star oriented, therefore all the packets follow the		o Topology is star oriented, therefore all the packets follow the
	same path. For the needs of this draft, the architecture can be		same path. For the needs of this draft, the architecture can be
	summarized to Things or End-Systems (ES) exchanging information		summarized to Devices (DEV) exchanging information with LPWAN
	with LPWAN Application Server (LA) through a Network Gateway (NG).		Application Server (APP) through a Network Gateway (NGW).
	o Traffic flows are mostly known in advanced, since End-Systems		o Traffic flows are mostly known in advance, since devices embed
	embed built-in applications. Contrary to computers or		built-in applications. Contrary to computers or smartphones, new
	smartphones, new applications cannot be easily installed.		applications cannot be easily installed.
	The Static Context Header Compression (SCHC) is defined for this		The Static Context Header Compression (SCHC) is defined for this
	environment. SCHC uses a context where header information is kept in		environment. SCHC uses a context where header information is kept in
	order, this context is static the values on the header fields do not		order. This context is static (the values on the header fields do
	change during time, avoiding complex resynchronization mechanisms,		not change during time) avoiding complex resynchronization
	incompatible with LPWAN characteristics. In most of the cases, IPv6/		mechanisms, incompatible with LPWAN characteristics. In most of the
	UDP headers are reduced to a small context identifier.		cases, IPv6/UDP headers are reduced to a small context identifier.
	The SCHC header compression is indedependent of the specific LPWAN		The SCHC header compression is indedependent of the specific LPWAN
	technology over which it will be used.		technology over which it will be used.
	On the other hand, LPWAN technologies are characterized, among		On the other hand, LPWAN technologies are characterized, among
	others, by a very reduced data unit and/or payload size		others, by a very reduced data unit and/or payload size
	[I-D.ietf-lpwan-overview]. However, some of these technologies do		[I-D.ietf-lpwan-overview]. However, some of these technologies do
	not support layer two fragmentation, therefore the only option for		not support layer two fragmentation, therefore the only option for
	these to support IPv6 when header compression is not possible (and,		these to support the IPv6 MTU requirement of 1280 bytes [RFC2460] is
	in particular, its MTU requirement of 1280 bytes [RFC2460]) is the		the use of a fragmentation mechanism at the adaptation layer below
	use of fragmentation mechanism at the adaptation layer below IPv6.		IPv6. This specification defines fragmentation functionality to
	This specification defines fragmentation functionality to support the		support the IPv6 MTU requirements over LPWAN technologies. Such
	IPv6 MTU requirements over LPWAN technologies.		functionality has been designed under the assumption that data unit
			reordering will not happen between the entity performing
			fragmentation and the entity performing reassembly.
	2. Vocabulary		2. Vocabulary
	This section defines the terminology and aconyms used in this		This section defines the terminology and acronyms used in this
	document.		document.
	o CDF: Compression/Decompression Function. A function that is used		o CDA: Compression/Decompression Action. An action that is perfomed
	for both functionnalities to compress a header field or to recover		for both functionnalities to compress a header field or to recover
	its original value in the decompression phase.		its original value in the decompression phase.
	o Context: A set of rules used to compress/decompress headers		o Context: A set of rules used to compress/decompress headers
	o ES: End System. Node connected to the LPWAN. An ES may implement		o DEV: Device. Node connected to the LPWAN. A DEV may implement
	SCHC.		SCHC.
	o LA: LPWAN Application. An application sending/consuming IPv6		o APP: LPWAN Application. An application sending/consuming IPv6
	packets to/from the End System.		packets to/from the Device.
	o LC: LPWAN Compressor/Decompressor. A process in the network to		o SCHC C/D: LPWAN Compressor/Decompressor. A process in the network
	achieve compression/decompressing headers. LC uses SCHC rules to		to achieve compression/decompressing headers. SCHC C/D uses SCHC
	perform compression and decompression.		rules to perform compression and decompression.
	o MO: Matching Operator. An operator used to compare a value		o MO: Matching Operator. An operator used to compare a value
	contained in a header field with a value contained in a rule.		contained in a header field with a value contained in a rule.
	o Rule: A set of header field values.		o Rule: A set of header field values.
	o Rule ID: An identifier for a rule, LC and ES share the same rule		o Rule ID: An identifier for a rule, SCHC C/D and DEV share the same
	ID for a specific flow. Rule ID is sent on the LPWAN.		rule ID for a specific flow. Rule ID is sent on the LPWAN.
	o TV: Target value. A value contained in the rule that will be		o TV: Target value. A value contained in the rule that will be
	matched with the value of a header field.		matched with the value of a header field.
	3. Static Context Header Compression		3. 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
	other header compression mechanisms such as RoHC. Based on the fact		other header compression mechanisms such as RoHC. Based on the fact
	that the nature of data flows is highly predictable in LPWAN		that the nature of data flows is highly predictable in LPWAN
	networks, a static context may be stored on the End-System (ES). The		networks, a static context may be stored on the Device (DEV). The
	context must be stored in both ends. It can also be learned by using		context must be stored in both ends. It can also be learned by using
	a provisionning protocol that is out of the scope of this draft.		a provisionning protocol that is out of the scope of this draft.
	End-System Appl Servers		DEVICE Appl Servers
	+-----------------+ +---------------+		+---------------+ +---------------+
	| APP1 APP2 APP3 | |APP1 APP2 APP3|		| APP1 APP2 APP3| |APP1 APP2 APP3|
	| | | |		| | | |
	| UDP | | UDP |		| UDP | | UDP |
	| IPv6 | | IPv6 |		| IPv6 | | IPv6 |
	| | | |		| | | |
	| LC (contxt)| | |		| SCHC C/D | | |
	+--------+--------+ +-------+-------+		| (context) | | |
	| +--+ +--+ +-----------+ .		+--------+------+ +-------+-------+
	+~~ |RG| === |NG| === |LC (contxt)| ... Internet ...		| +--+ +----+ +---------+ .
	+--+ +--+ +-----+-----+		+~~ |RG| === |NGW | === |SCHC C/D |... Internet ...
			+--+ +----+ |(context)|
			+---------+
	Figure 1: Architecture		Figure 1: Architecture
	Figure 1 based on [I-D.ietf-lpwan-overview] terminology represents		Figure 1 based on [I-D.ietf-lpwan-overview] terminology represents
	the architecture for compression/decompression. The Thing or End-		the architecture for compression/decompression. The Device is
	System is running applications which produce IPv6 or IPv6/UDP flows.		running applications which produce IPv6 or IPv6/UDP flows. These
	These flows are compressed by a LPWAN Compressor (LC) to reduce the		flows are compressed by an Static Context Header Compression
	headers size. Resulting information is sent on a layer two (L2)		Compressor/Decompressor (SCHC C/D) to reduce the headers size.
	frame to the LPWAN Radio Network to a Radio Gateway (RG) which		Resulting information is sent on a layer two (L2) frame to the LPWAN
	forwards the frame to a Network Gateway. The Network Gateway sends		Radio Network to a Radio Gateway (RG) which forwards the frame to a
	the data to a LC for decompression which shares the same rules with		Network Gateway (NGW). The NGW sends the data to a SCHC C/D for
	the ES. The LC can be located on the Network Gateway or in another		decompression which shares the same rules with the DEV. The SCHC C/D
	places if a tunnel is established between the NG and the LC. This		can be located on the Network Gateway (NGW) or in another places if a
			tunnel is established between the NGW and the SCHC C/D. This
	architecture forms a star topology. After decompression, the packet		architecture forms a star topology. After decompression, the packet
	can be sent on the Internet to one or several LPWAN Application		can be sent on the Internet to one or several LPWAN Application
	Servers (LA).		Servers (APP).
	The principle is exactly the same in the other direction.		The principle is exactly the same in the other direction.
	The context contains a list of rules (cf. Figure 2). Each rule		The context contains a list of rules (cf. Figure 2). Each rule
	contains itself a list of fields descriptions composed of a field		contains itself a list of fields descriptions composed of a field
	identifier (FID), a target value (TV), a matching operator (MO) and a		identifier (FID), a field position (FP), a direction indicator (DI),
	Compression/Decompression Function (CDF).		a target value (TV), a matching operator (MO) and a Compression/
			Decompression Action (CDA).
	+-----------------------------------------------------------------+		/----------------------------------------------------------------\
	| Rule N |		| Rule N |
	+----------------------------------------------------------------+ |		/----------------------------------------------------------------\|
	| Rule i | |		| Rule i ||
	+---------------------------------------------------------------+ | |		/----------------------------------------------------------------\||
	| Rule 1 | | |		| (FID) Rule 1 |||
	|+--------+--------------+-------------------+-----------------+| | |		|+-------+---+---+------------+-----------------+---------------+|||
	||Field 1 | Target Value | Matching Operator | Comp/Decomp Fct || | |		||Field 1|Pos|Dir|Target Value|Matching Operator|Comp/Decomp Act||||
	|+--------+--------------+-------------------+-----------------+| | |		|+-------+---+---+------------+-----------------+---------------+|||
	||Field 2 | Target Value | Matching Operator | Comp/Decomp Fct || | |		||Field 2|Pos|Dir|Target Value|Matching Operator|Comp/Decomp Act||||
	|+--------+--------------+-------------------+-----------------+| | |		|+-------+---+---+------------+-----------------+---------------+|||
	||... | ... | ... | ... || | |		||... |...|...| ... | ... | ... ||||
	|+--------+--------------+-------------------+-----------------+| |-+		|+-------+---+---+------------+-----------------+---------------+||/
	||Field N | Target Value | Matching Operator | Comp/Decomp Fct || |		||Field N|Pos|Dir|Target Value|Matching Operator|Comp/Decomp Act|||
	|+--------+--------------+-------------------+-----------------+|-+		|+-------+---+---+------------+-----------------+---------------+|/
	| |		| |
	+---------------------------------------------------------------+		\----------------------------------------------------------------/
	Figure 2: Compression Decompression Context		Figure 2: Compression Decompression Context
	The rule does not describe the original packet format which must be		The rule does not describe the original packet format which must be
	known from the compressor/decompressor. The rule just describes the		known from the compressor/decompressor. The rule just describes the
	compression/decompression behavior for the header fields. In the		compression/decompression behavior for the header fields. In the
	rule, it is recommended to describe the header field in the same		rule, the description of the header field must be done in the same
	order they appear in the packet.		order they appear in the packet.
			On the other hand, the rule describes the compressed header which are
			transmitted regarding their position in the rule which is used for
			data serialization on the compressor side and data deserialization on
			the decompressor side.
	The main idea of the compression scheme is to send the rule id to the		The main idea of the compression scheme is to send the rule id to the
	other end instead of known field values. When a value is known by		other end instead of known field values. When a value is known by
	both ends, it is not necessary to send it on the LPWAN network.		both ends, it is not necessary to send it on the LPWAN network.
	The field description is composed of different entries:		The field description is composed of different entries:
	o A Field ID (FID) is a unique value to define the field.		o A Field ID (FID) is a unique value to define the field.
			o A Field Position (FP) indicating if several instances of the field
			exist in the headers which one is targeted.
			o A direction indicator (DI) indicating the packet direction. Three
			values are possible:
			* upstream when the field or the value is only present in packets
			sent by the DEV to the APP,
			* downstream when the field or the value is only present in
			packet sent from the APP to the DEV and
			* bi-directional when the field or the value is present either
			upstream or downstream.
	o A Target Value (TV) is the value used to make the comparison with		o A Target Value (TV) is the value used to make the comparison with
	the packet header field. The Target Value can be of any type		the packet header field. The Target Value can be of any type
	(integer, strings,...). It can be a single value or a more		(integer, strings,...). It can be a single value or a more
	complex structure (array, list,...). It can be considered as a		complex structure (array, list,...). It can be considered as a
	CBOR structure.		CBOR structure.
	o A Matching Operator (MO) is the operator used to make the		o A Matching Operator (MO) is the operator used to make the
	comparison between the field value and the Target Value. The		comparison between the field value and the Target Value. The
	Matching Operator may require some parameters, which can be		Matching Operator may require some parameters, which can be
	considered as a CBOR structure. MO is only used during the		considered as a CBOR structure. MO is only used during the
	compression phase.		compression phase.
	o A Compression Decompression Function (CDF) is used to describe the		o A Compression Decompression Action (CDA) is used to describe the
	compression and the decompression process. The CDF may require		compression and the decompression process. The CDA may require
	some parameters, which can be considered as a CBOR structure.		some parameters, which can be considered as a CBOR structure.
	3.1. Rule ID		3.1. Rule ID
	Rule IDs are sent between both compression/decompression elements.		Rule IDs are sent between both compression/decompression elements.
	The size of the rule ID is not specified in this document and can		The size of the rule ID is not specified in this document and can
	vary regarding the LPWAN technology, the number of flows,...		vary regarding the LPWAN technology, the number of flows,...
	Some values in the rule ID space may be reserved for goals other than		Some values in the rule ID space may be reserved for goals other than
	header compression, for example fragmentation.		header compression, for example fragmentation.
	Rule IDs are specific to an ES. Two ESs may use the same rule ID for		Rule IDs are specific to a DEV. Two DEVs may use the same rule ID
	different header compression. The LC needs to combine the rule ID		for different header compression. The SCHC C/D needs to combine the
	with the ES L2 address to find the appropriate rule.		rule ID with the DEV L2 address to find the appropriate rule.
	3.2. Packet processing		3.2. Packet processing
	The compression/decompression process follows several steps:		The compression/decompression process follows several steps:
	o compression rule selection: the goal is to identify which rule(s)		o compression rule selection: the goal is to identify which rule(s)
	will be used to compress the headers. Each field is associated to		will be used to compress the headers. Each field is associated to
	a matching operator for compression. Each header field's value is		a matching operator for compression. Each header field's value is
	compared to the corresponding target value stored in the rule for		compared to the corresponding target value stored in the rule for
	that field using the matching operator. If all the fields in the		that field using the matching operator. This comparison includes
	packet's header satisfied all the matching operators of a rule,		the direction indicator and the field position in the header. If
	the packet is processed using Compression Decompression Function		all the fields in the packet's header satisfy all the matching
	associated with the fields. Otherwise the next rule is tested.		operators (excluding unappropriate direction or position) of a
	If no eligible rule is found, then the packet is sent without		rule, the packet is processed using Compression Decompression
	compression, which may require using the fragmentation procedure.		Function associated with the fields. Otherwise the next rule is
			tested. If no eligible rule is found, then the packet is sent
			without compression, which may require using the fragmentation
			procedure.
			In the downstrean direction, the rule is also used to find the
			device ID.
	o sending: The rule ID is sent to the other end followed by		o sending: The rule ID is sent to the other end followed by
	information resulting from the compression of header fields. This		information resulting from the compression of header fields. This
	information is sent in the order expressed in the rule for the		information is sent in the order expressed in the rule for the
	matching fields. The way the rule ID is sent depends on the layer		matching fields. The way the rule ID is sent depends on the layer
	two technology and will be specified in a specific document. For		two technology and will be specified in a specific document. For
	example, it can either be included in a Layer 2 header or sent in		example, it can either be included in a Layer 2 header or sent in
	the first byte of the L2 payload.		the first byte of the L2 payload. (cf. Figure 3)
	o decompression: The receiver identifies the sender through its		o decompression: The receiver identifies the sender through its
	device-id (e.g. MAC address) and selects the appropriate rule		device-id (e.g. MAC address) and selects the appropriate rule
	through the rule ID. This rule gives the compressed header format		through the rule ID. This rule gives the compressed header format
	and associates these values to header fields. It applies the CDF		and associates these values to header fields. It applies the CDA
	function to reconstruct the original header fields. CDF of		action to reconstruct the original header fields. The CDA order
	Compute-* must be applied after the other CDFs.		can be different of the order given by the rule. For instance
			Compute-* may be applied after the other CDAs.
			+--- ... ---+-------------- ... --------------+
			| Rule ID |Compressed Hdr Fields information|
			+--- ... ---+-------------- ... --------------+
			Figure 3: LPWAN Compressed Format Packet
	4. Matching operators		4. Matching operators
	This document describes basic matching operators (MO)s which must be		This document describes basic matching operators (MO)s which must be
	known by both LC, endpoints involved in the header compression/		known by both SCHC C/D, endpoints involved in the header compression/
	decompression. They are not typed and can be applied indifferently		decompression. They are not typed and can be applied indifferently
	to integer, string or any other type. The MOs and their definition		to integer, string or any other type. The MOs and their definitions
	are provided next:		are provided next:
	o equal: a field value in a packet matches with a field value in a		o equal: a field value in a packet matches with a field value in a
	rule if they are equal.		rule if they are equal.
	o ignore: no check is done between a field value in a packet and a		o ignore: no check is done between a field value in a packet and a
	field value in the rule. The result of the matching is always		field value in the rule. The result of the matching is always
	true.		true.
	o MSB(length): a field value of a size equal to "length" bits in a		o MSB(length): a field value of a size equal to "length" bits in a
	packet matches with a field value in a rule if the most		packet matches with a field value in a rule if the most
	significant "length" bits are equal.		significant "length" bits are equal.
	o match-mapping: The goal of mapping-sent is to reduce the size of a		o match-mapping: The goal of mapping-sent is to reduce the size of a
	field by allocating a shorter value. The Target Value contains a		field by allocating a shorter value. The Target Value contains a
	list of pairs. Each pair is composed of a value and a short ID.		list of pairs. Each pair is composed of a value and a short ID
	This operator matches if a field value is equal to one of the		(or index). This operator matches if a field value is equal to
	pairs' values.		one of the pairs' values.
	Matching Operators may need a list of parameters to proceed to the		Matching Operators and match-mapping needs a parameter to proceed to
	matching. For instance MSB requires an integer indicating the number		the matching. Match-mapping requires a list of values associated to
	of bits to test.		an index and MSB requires an integer indicating the number of bits to
			test.
	5. Compression Decompression Functions (CDF)		5. Compression Decompression Actions (CDA)
	The Compression Decompression Functions (CDF) describes the action		The Compression Decompression Actions (CDA) describes the action
	taken during the compression of headers fields, and inversely, the		taken during the compression of headers fields, and inversely, the
	action taken by the decompressor to restore the original value.		action taken by the decompressor to restore the original value.
	/--------------------+-------------+---------------------------\		/--------------------+-------------+----------------------------\
	| Function | Compression | Decompression |		| Action | Compression | Decompression |
	| | | |		| | | |
	+--------------------+-------------+---------------------------+		+--------------------+-------------+----------------------------+
	|not-sent |elided |use value stored in ctxt |		|not-sent |elided |use value stored in ctxt |
	|value-sent |send |build from received value |		|value-sent |send |build from received value |
	|LSB(length) |send LSB |ctxt value OR rcvd value |		|mapping-sent |send index |value from index on a table |
	|compute-length |elided |compute length |		|LSB(length) |send LSB |ctxt value OR rcvd value |
	|compute-checksum |elided |compute UDP checksum |		|compute-length |elided |compute length |
	|ESiid-DID |elided |build IID from L2 ES addr |		|compute-checksum |elided |compute UDP checksum |
	|LAiid-DID |elided |build IID from L2 LA addr |		|DEViid-DID |elided |build IID from L2 DEV addr |
	|mapping-sent |send index |value from index on a table|		|APPiid-DID |elided |build IID from L2 APP addr |
	\--------------------+-------------+---------------------------/		\--------------------+-------------+----------------------------/
	Figure 3: Compression and Decompression Functions		Figure 4: Compression and Decompression Functions
	Figure 3 sumarizes the functions defined to compress and decompress a		Figure 4 sumarizes the functions defined to compress and decompress a
	field. The first column gives the function's name. The second and		field. The first column gives the action's name. The second and
	third columns outlines the compression/decompression behavior.		third columns outlines the compression/decompression behavior.
	Compression is done in the rule order and compressed values are sent		Compression is done in the rule order and compressed values are sent
	in that order in the compressed message. The receiver must be able		in that order in the compressed message. The receiver must be able
	to find the size of each compressed field which can be given by the		to find the size of each compressed field which can be given by the
	rule or may be sent with the compressed header.		rule or may be sent with the compressed header.
	5.1. not-sent CDF		5.1. not-sent CDA
	Not-sent function is generally used when the field value is specified		Not-sent function is generally used when the field value is specified
	in the rule and therefore known by the both Compressor and		in the rule and therefore known by the both Compressor and
	Decompressor. This function is generally used with the "equal" MO.		Decompressor. This action is generally used with the "equal" MO. If
	If MO is "ignore", there is a risk to have a decompressed field value		MO is "ignore", there is a risk to have a decompressed field value
	different from the compressed field.		different from the compressed field.
	The compressor does not send any value on the compressed header for		The compressor does not send any value on the compressed header for
	that field on which compression is applied.		that field on which compression is applied.
	The decompressor restores the field value with the target value		The decompressor restores the field value with the target value
	stored in the matched rule.		stored in the matched rule.
	5.2. value-sent CDF		5.2. value-sent CDA
	The value-sent function is generally used when the field value is not		The value-sent action is generally used when the field value is not
	known by both Compressor and Decompressor. The value is sent in the		known by both Compressor and Decompressor. The value is sent in the
	compressed message header. Both Compressor and Decompressor must		compressed message header. Both Compressor and Decompressor must
	know the size of the field, either implicitely (the size is known by		know the size of the field, either implicitly (the size is known by
	both sides) or explicitely in the compressed header field by		both sides) or explicitly in the compressed header field by
	indicating the length. This function is generally used with the		indicating the length. This function is generally used with the
	"ignore" MO.		"ignore" MO.
	The compressor sends the Target Value stored on the rule in the		The compressor sends the Target Value stored on the rule in the
	compressed header message. The decompressor restores the field value		compressed header message. The decompressor restores the field value
	with the one received from the LPWAN		with the one received from the LPWAN
	5.3. LSB CDF		5.3. mapping-sent
	LSB function is used to send a fixed part of the packet field header		mapping-sent is used to send a smaller index associated to the field
	to the other end. This function is used together with the "MSB" MO		value in the Target Value. This function is used together with the
			"match-mapping" MO.
			The compressor looks in the TV to find the field value and send the
			corresponding index. The decompressor uses this index to restore the
			field value.
			The number of bit sent is the minimal number to code all the indexes.
			5.4. LSB CDA
			LSB action is used to send a fixed part of the packet field header to
			the other end. This action is used together with the "MSB" MO. A
			length can be specified to indicate how many bits have to be sent.
			If not length is specified, the number of bit sent are the field
			length minus the bit length specified in the MSB MO.
	The compressor sends the "length" Least Significant Bits. The		The compressor sends the "length" Least Significant Bits. The
	decompressor combines with an OR operator the value received with the		decompressor combines with an OR operator the value received with the
	Target Value.		Target Value.
	5.4. ESiid-DID, LAiid-DID CDF		5.5. DEViid-DID, APPiid-DID CDA
	These functions are used to process respectively the End System and		These functions are used to process respectively the Device and the
	the LA Device Identifier (DID).		Application Device Identifier (DID). APPiid-DID CDA is less common,
			since current LPWAN technologies frames contain a single address.
	The IID value is computed from the device ID present in the Layer 2		The IID value is computed from the Device ID present in the Layer 2
	header. The computation depends on the technology and the device ID		header. The computation depends on the technology and the Device ID
	size.		size.
	5.5. mapping-sent		In the downstream direction, these CDA are used to determine the L2
			addresses used by the LPWAN.
	mapping-sent is used to send a smaller index associated to the field
	value in the Target Value. This function is used together with the
	"match-mapping" MO.
	The compressor looks in the TV to find the field value and send the
	corresponding index. The decompressor uses this index to restore the
	field value.
	5.6. Compute-*		5.6. Compute-*
	These functions are used by the decompressor to compute the		These functions are used by the decompressor to compute the
	compressed field value based on received information. Compressed		compressed field value based on received information. Compressed
	fields are elided during the compression and reconstructed during the		fields are elided during the compression and reconstructed during the
	decompression.		decompression.
	o compute-length: compute the length assigned to this field. For		o compute-length: compute the length assigned to this field. For
	instance, regarding the field ID, this CDF may be used to compute		instance, regarding the field ID, this CDA may be used to compute
	IPv6 length or UDP length.		IPv6 length or UDP length.
	o compute-checksum: compute a checksum from the information already		o compute-checksum: compute a checksum from the information already
	received by the LC. This field may be used to compute UDP		received by the SCHC C/D. This field may be used to compute UDP
	checksum.		checksum.
	6. Application to IPv6 and UDP headers		6. Application to IPv6 and UDP headers
	This section lists the different IPv6 and UDP header fields and how		This section lists the different IPv6 and UDP header fields and how
	they can be compressed.		they can be compressed.
	6.1. IPv6 version field		6.1. IPv6 version field
	This field always holds the same value, therefore the TV is 6, the MO		This field always holds the same value, therefore the TV is 6, the MO
	is "equal" and the CDF "not-sent".		is "equal" and the CDA "not-sent".
	6.2. IPv6 Traffic class field		6.2. IPv6 Traffic class field
	If the DiffServ field identified by the rest of the rule do not vary		If the DiffServ field identified by the rest of the rule do not vary
	and is known by both sides, the TV should contain this wellknown		and is known by both sides, the TV should contain this wellknown
	value, the MO should be "equal" and the CDF must be "not-sent.		value, the MO should be "equal" and the CDA must be "not-sent.
	If the DiffServ field identified by the rest of the rule varies over		If the DiffServ field identified by the rest of the rule varies over
	time or is not known by both sides, then there are two possibilities		time or is not known by both sides, then there are two possibilities
	depending on the variability of the value, the first one there is		depending on the variability of the value, the first one there is
	without compression and the original value is sent, or the sencond		without compression and the original value is sent, or the sencond
	where the values can be computed by sending only the LSB bits:		where the values can be computed by sending only the LSB bits:
	o TV is not set, MO is set to "ignore" and CDF is set to "value-		o TV is not set, MO is set to "ignore" and CDA is set to "value-
	sent"		sent"
	o TV contains a stable value, MO is MSB(X) and CDF is set to		o TV contains a stable value, MO is MSB(X) and CDA is set to
	LSB(8-X)		LSB(8-X)
	6.3. Flow label field		6.3. Flow label field
	If the Flow Label field identified by the rest of the rule does not		If the Flow Label field identified by the rest of the rule does not
	vary and is known by both sides, the TV should contain this well-		vary and is known by both sides, the TV should contain this well-
	known value, the MO should be "equal" and the CDF should be "not-		known value, the MO should be "equal" and the CDA should be "not-
	sent".		sent".
	If the Flow Label field identified by the rest of the rule varies		If the Flow Label field identified by the rest of the rule varies
	during time or is not known by both sides, there are two		during time or is not known by both sides, there are two
	possibilities dpending on the variability of the value, the first one		possibilities dpending on the variability of the value, the first one
	is without compression and then the value is sent and the second		is without compression and then the value is sent and the second
	where only part of the value is sent and the decompressor needs to		where only part of the value is sent and the decompressor needs to
	compute the original value:		compute the original value:
	o TV is not set, MO is set to "ignore" and CDF is set to "value-		o TV is not set, MO is set to "ignore" and CDA is set to "value-
	sent"		sent"
	o TV contains a stable value, MO is MSB(X) and CDF is set to		o TV contains a stable value, MO is MSB(X) and CDA is set to
	LSB(20-X)		LSB(20-X)
	6.4. Payload Length field		6.4. Payload Length field
	If the LPWAN technology does not add padding, this field can be		If the LPWAN technology does not add padding, this field can be
	elided for the transmission on the LPWAN network. The LC recompute		elided for the transmission on the LPWAN network. The SCHC C/D
	the original payload length value. The TV is not set, the MO is set		recompute the original payload length value. The TV is not set, the
	to "ignore" and the CDF is "compute-IPv6-length".		MO is set to "ignore" and the CDA is "compute-IPv6-length".
	If the payload is small, the TV can be set to 0x0000, the MO set to		If the payload is small, the TV can be set to 0x0000, the MO set to
	"MSB (16-s)" and the CDF to "LSB (s)". The 's' parameter depends on		"MSB (16-s)" and the CDA to "LSB (s)". The 's' parameter depends on
	the maximum packet length.		the maximum packet length.
	On other cases, the payload length field must be sent and the CDF is		On other cases, the payload length field must be sent and the CDA is
	replaced by "value-sent".		replaced by "value-sent".
	6.5. Next Header field		6.5. Next Header field
	If the Next Header field identified by the rest of the rule does not		If the Next Header field identified by the rest of the rule does not
	vary and is known by both sides, the TV should contain this Next		vary and is known by both sides, the TV should contain this Next
	Header value, the MO should be "equal" and the CDF should be "not-		Header value, the MO should be "equal" and the CDA should be "not-
	sent".		sent".
	If the Next header field identified by the rest of the rule varies		If the Next header field identified by the rest of the rule varies
	during time or is not known by both sides, then TV is not set, MO is		during time or is not known by both sides, then TV is not set, MO is
	set to "ignore" and CDF is set to "value-sent".		set to "ignore" and CDA is set to "value-sent". A matching-list may
			also be used.
	6.6. Hop Limit field		6.6. Hop Limit field
	The End System is generally a host and does not forward packets,		The End System is generally a host and does not forward packets,
	therefore the Hop Limit value is constant. So the TV is set with a		therefore the Hop Limit value is constant. So the TV is set with a
	default value, the MO is set to "equal" and the CDF is set to "not-		default value, the MO is set to "equal" and the CDA is set to "not-
	sent".		sent".
	Otherwise the value is sent on the LPWAN: TV is not set, MO is set to		Otherwise the value is sent on the LPWAN: TV is not set, MO is set to
	ignore and CDF is set to "value-sent".		ignore and CDA is set to "value-sent".
			Note that the field behavior differs in upstream and downstream. In
			upstream, since there is no IP forwarding between the DEV and the
			SCHC C/D, the value is relatively constant. On the other hand, the
			downstream value depends of Internet routing and may change more
			frequently. One solution could be to use the Direction Indicator
			(DI) to distinguish both directions to elide the field in the
			upstream direction and send the value in the downstream direction.
	6.7. IPv6 addresses fields		6.7. IPv6 addresses fields
	As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit		As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit
	long fields; one for the prefix and one for the Interface Identifier		long fields; one for the prefix and one for the Interface Identifier
	(IID). These fields should be compressed. To allow a single rule,		(IID). These fields should be compressed. To allow a single rule,
	these values are identified by their role (ES or LA) and not by their		these values are identified by their role (DEV or APP) and not by
	position in the frame (source or destination). The LC must be aware		their position in the frame (source or destination). The SCHC C/D
	of the traffic direction (upstream, downstream) to select the		must be aware of the traffic direction (upstream, downstream) to
	appropriate field.		select the appropriate field.
	6.7.1. IPv6 source and destination prefixes		6.7.1. IPv6 source and destination prefixes
	Both ends must be synchronized with the appropriate prefixes. For a		Both ends must be synchronized with the appropriate prefixes. For a
	specific flow, the source and destination prefix can be unique and		specific flow, the source and destination prefix can be unique and
	stored in the context. It can be either a link-local prefix or a		stored in the context. It can be either a link-local prefix or a
	global prefix. In that case, the TV for the source and destination		global prefix. In that case, the TV for the source and destination
	prefixes contains the values, the MO is set to "equal" and the CDF is		prefixes contains the values, the MO is set to "equal" and the CDA is
	set to "not-sent".		set to "not-sent".
	In case the rule allows several prefixes, static mapping must be		In case the rule allows several prefixes, mapping-list must be used.
	used. The different prefixes are listed in the TV associated with a		The different prefixes are listed in the TV associated with a short
	short ID. The MO is set to "match-mapping" and the CDF is set to		ID. The MO is set to "match-mapping" and the CDA is set to "mapping-
	"mapping-sent".		sent".
	Otherwise the TV contains the prefix, the MO is set to "equal" and		Otherwise the TV contains the prefix, the MO is set to "equal" and
	the CDF is set to value-sent.		the CDA is set to value-sent.
	6.7.2. IPv6 source and destination IID		6.7.2. IPv6 source and destination IID
	If the ES or LA IID are based on an LPWAN address, then the IID can		If the DEV or APP IID are based on an LPWAN address, then the IID can
	be reconstructed with information coming from the LPWAN header. In		be reconstructed with information coming from the LPWAN header. In
	that case, the TV is not set, the MO is set to "ignore" and the CDF		that case, the TV is not set, the MO is set to "ignore" and the CDA
	is set to "ESiid-DID" or "LAiid-DID". Note that the LPWAN technology		is set to "DEViid-DID" or "APPiid-DID". Note that the LPWAN
	is generally carrying a single device identifier corresponding to the		technology is generally carrying a single device identifier
	ES. The LC may also not be aware of these values.		corresponding to the DEV. The SCHC C/D may also not be aware of
			these values.
	For privacy reasons or if the ES address is changing over time, it		For privacy reasons or if the DEV address is changing over time, it
	maybe better to use a static value. In that case, the TV contains		maybe better to use a static value. In that case, the TV contains
	the value, the MO operator is set to "equal" and the CDF is set to		the value, the MO operator is set to "equal" and the CDA is set to
	"not-sent".		"not-sent".
	If several IIDs are possible, then the TV contains the list of		If several IIDs are possible, then the TV contains the list of
	possible IID, the MO is set to "match-mapping" and the CDF is set to		possible IID, the MO is set to "match-mapping" and the CDA is set to
	"mapping-sent".		"mapping-sent".
	Otherwise the value variation of the IID may be reduced to few bytes.		Otherwise the value variation of the IID may be reduced to few bytes.
	In that case, the TV is set to the stable part of the IID, the MO is		In that case, the TV is set to the stable part of the IID, the MO is
	set to MSB and the CDF is set to LSB.		set to MSB and the CDF is set to LSB.
	Finally, the IID can be sent on the LPWAN. In that case, the TV is		Finally, the IID can be sent on the LPWAN. In that case, the TV is
	not set, the MO is set to "ignore" and the CDF is set to "value-		not set, the MO is set to "ignore" and the CDA is set to "value-
	sent".		sent".
	6.8. IPv6 extensions		6.8. IPv6 extensions
	No extension rules are currently defined. They can be based on the		No extension rules are currently defined. They can be based on the
	MOs and CDFs described above.		MOs and CDAs described above.
	6.9. UDP source and destination port		6.9. UDP source and destination port
	To allow a single rule, the UDP port values are identified by their		To allow a single rule, the UDP port values are identified by their
	role (ES or LA) and not by their position in the frame (source or		role (DEV or APP) and not by their position in the frame (source or
	destination). The LC must be aware of the traffic direction		destination). The SCHC C/D must be aware of the traffic direction
	(upstream, downstream) to select the appropriate field. The		(upstream, downstream) to select the appropriate field. The
	following rules apply for ES and LA port numbers.		following rules apply for DEV and APP port numbers.
	If both ends knows the port number, it can be elided. The TV		If both ends knows the port number, it can be elided. The TV
	contains the port number, the MO is set to "equal" and the CDF is set		contains the port number, the MO is set to "equal" and the CDA is set
	to "not-sent".		to "not-sent".
	If the port variation is on few bits, the TV contains the stable part		If the port variation is on few bits, the TV contains the stable part
	of the port number, the MO is set to "MSB" and the CDF is set to		of the port number, the MO is set to "MSB" and the CDA is set to
	"LSB".		"LSB".
	If some well-known values are used, the TV can contain the list of		If some well-known values are used, the TV can contain the list of
	this values, the MO is set to "match-mapping" and the CDF is set to		this values, the MO is set to "match-mapping" and the CDA is set to
	"mapping-sent".		"mapping-sent".
	Otherwise the port numbers are sent on the LPWAN. The TV is not set,		Otherwise the port numbers are sent on the LPWAN. The TV is not set,
	the MO is set to "ignore" and the CDF is set to "value-sent".		the MO is set to "ignore" and the CDA is set to "value-sent".
	6.10. UDP length field		6.10. UDP length field
	If the LPWAN technology does not introduce padding, the UDP length		If the LPWAN technology does not introduce padding, the UDP length
	can be computed from the received data. In that case the TV is not		can be computed from the received data. In that case the TV is not
	set, the MO is set to "ignore" and the CDF is set to "compute-UDP-		set, the MO is set to "ignore" and the CDA is set to "compute-UDP-
	length".		length".
	If the payload is small, the TV can be set to 0x0000, the MO set to		If the payload is small, the TV can be set to 0x0000, the MO set to
	"MSB" and the CDF to "LSB".		"MSB" and the CDA to "LSB".
	On other cases, the length must be sent and the CDF is replaced by		On other cases, the length must be sent and the CDA is replaced by
	"value-sent".		"value-sent".
	6.11. UDP Checksum field		6.11. UDP Checksum field
	IPv6 mandates a checksum in the protocol above IP. Nevertheless, if		IPv6 mandates a checksum in the protocol above IP. Nevertheless, if
	a more efficient mechanism such as L2 CRC or MIC is carried by or		a more efficient mechanism such as L2 CRC or MIC is carried by or
	over the L2 (such as in the LPWAN fragmentation process (see XXXX)),		over the L2 (such as in the LPWAN fragmentation process (see XXXX)),
	the UDP checksum transmission can be avoided. In that case, the TV		the UDP checksum transmission can be avoided. In that case, the TV
	is not set, the MO is set to "ignore" and the CDF is set to "compute-		is not set, the MO is set to "ignore" and the CDA is set to "compute-
	UDP-checksum".		UDP-checksum".
	In other cases the checksum must be explicitly sent. The TV is not		In other cases the checksum must be explicitly sent. The TV is not
	set, the MO is set to "ignore" and the CDF is set to "value-sent".		set, the MO is set to "ignore" and the CDF is set to "value-sent".
	7. Examples		7. Examples
	This section gives some scenarios of the compression mechanism for		This section gives some scenarios of the compression mechanism for
	IPv6/UDP. The goal is to illustrate the SCHC behavior.		IPv6/UDP. The goal is to illustrate the SCHC behavior.
	7.1. IPv6/UDP compression		7.1. IPv6/UDP compression
	The most common case using the mechanisms defined in this document		The most common case using the mechanisms defined in this document
	will be a LPWAN end-system that embeds some applications running over		will be a LPWAN DEV that embeds some applications running over CoAP.
	CoAP. In this example, three flows are considered. The first flow		In this example, three flows are considered. The first flow is for
	is for the device management based on CoAP using Link Local IPv6		the device management based on CoAP using Link Local IPv6 addresses
	addresses and UDP ports 123 and 124 for ES and LA, respectively. The		and UDP ports 123 and 124 for DEV and APP, respectively. The second
	second flow will be a CoAP server for measurements done by the end-		flow will be a CoAP server for measurements done by the Device (using
	system (using ports 5683) and Global IPv6 Address prefixes		ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to
	alpha::IID/64 to beta::1/64. The last flow is for legacy		beta::1/64. The last flow is for legacy applications using different
	applications using different ports numbers, the destination IPv6		ports numbers, the destination IPv6 address prefix is gamma::1/64.
	address prefix is gamma::1/64.
	Figure 4 presents the protocol stack for this End-System. IPv6 and		Figure 5 presents the protocol stack for this Device. IPv6 and UDP
	UDP are represented with dotted lines since these protocols are		are represented with dotted lines since these protocols are
	compressed on the radio link.		compressed on the radio link.
	Managment Data		Managment Data
	+----------+---------+---------+		+----------+---------+---------+
	| CoAP | CoAP | legacy |		| CoAP | CoAP | legacy |
	+----||----+---||----+---||----+		+----||----+---||----+---||----+
	. UDP . UDP | UDP |		. UDP . UDP | UDP |
	................................		................................
	. IPv6 . IPv6 . IPv6 .		. IPv6 . IPv6 . IPv6 .
	+------------------------------+		+------------------------------+
	| SCHC Header compression |		| SCHC Header compression |
	| and fragmentation |		| and fragmentation |
	+------------------------------+		+------------------------------+
	| 6LPWA L2 technologies |		| LPWAN L2 technologies |
	+------------------------------+		+------------------------------+
	End System or LPWA GW		DEV or NGW
	Figure 4: Simplified Protocol Stack for LP-WAN		Figure 5: Simplified Protocol Stack for LP-WAN
	Note that in some LPWAN technologies, only the End Systems have a		Note that in some LPWAN technologies, only the DEVs have a device ID.
	device ID. Therefore, when such technologie are used, it is		Therefore, when such technologie are used, it is necessary to define
	necessary to define statically an IID for the Link Local address for		statically an IID for the Link Local address for the SCHC C/D.
	the LPWAN compressor.
	Rule 0		Rule 0
	+----------------+---------+--------+-------------++------+		+----------------+---------+--------+-------------++------+
	| Field | Value | Match | Function || Sent |		| Field | Value | Match | Function || Sent |
	+----------------+---------+----------------------++------+		+----------------+---------+----------------------++------+
	|IPv6 version |6 | equal | not-sent || |		|IPv6 version |6 | equal | not-sent || |
	|IPv6 DiffServ |0 | equal | not-sent || |		|IPv6 DiffServ |0 | equal | not-sent || |
	|IPv6 Flow Label |0 | equal | not-sent || |		|IPv6 Flow Label |0 | equal | not-sent || |
	|IPv6 Length | | ignore | comp-IPv6-l || |		|IPv6 Length | | ignore | comp-length || |
	|IPv6 Next Header|17 | equal | not-sent || |		|IPv6 Next Header|17 | equal | not-sent || |
	|IPv6 Hop Limit |255 | ignore | not-sent || |		|IPv6 Hop Limit |255 | ignore | not-sent || |
	|IPv6 ESprefix |FE80::/64| equal | not-sent || |		|IPv6 DEVprefix |FE80::/64| equal | not-sent || |
	|IPv6 ESiid | | ignore | ESiid-DID || |		|IPv6 DEViid | | ignore | DEViid-DID || |
	|IPv6 LCprefix |FE80::/64| equal | not-sent || |		|IPv6 APPprefix |FE80::/64| equal | not-sent || |
	|IPv6 LAiid |::1 | equal | not-sent || |		|IPv6 APPiid |::1 | equal | not-sent || |
	+================+=========+========+=============++======+		+================+=========+========+=============++======+
	|UDP ESport |123 | equal | not-sent || |		|UDP DEVport |123 | equal | not-sent || |
	|UDP LAport |124 | equal | not-sent || |		|UDP APPport |124 | equal | not-sent || |
	|UDP Length | | ignore | comp-length || |		|UDP Length | | ignore | comp-length || |
	|UDP checksum | | ignore | comp-chk || |		|UDP checksum | | ignore | comp-chk || |
	+================+=========+========+=============++======+		+================+=========+========+=============++======+
	Rule 1		Rule 1
	+----------------+---------+--------+-------------++------+		+----------------+---------+--------+-------------++------+
	| Field | Value | Match | Function || Sent |		| Field | Value | Match | Function || Sent |
	+----------------+---------+--------+-------------++------+		+----------------+---------+--------+-------------++------+
	|IPv6 version |6 | equal | not-sent || |		|IPv6 version |6 | equal | not-sent || |
	|IPv6 DiffServ |0 | equal | not-sent || |		|IPv6 DiffServ |0 | equal | not-sent || |
	|IPv6 Flow Label |0 | equal | not-sent || |		|IPv6 Flow Label |0 | equal | not-sent || |
	|IPv6 Length | | ignore | comp-IPv6-l || |		|IPv6 Length | | ignore | comp-length || |
	|IPv6 Next Header|17 | equal | not-sent || |		|IPv6 Next Header|17 | equal | not-sent || |
	|IPv6 Hop Limit |255 | ignore | not-sent || |		|IPv6 Hop Limit |255 | ignore | not-sent || |
	|IPv6 ESprefix |alpha/64 | equal | not-sent || |		|IPv6 DEVprefix |alpha/64 | equal | not-sent || |
	|IPv6 ESiid | | ignore | ESiid-DID || |		|IPv6 DEViid | | ignore | DEViid-DID || |
	|IPv6 LAprefix |beta/64 | equal | not-sent || |		|IPv6 APPprefix |beta/64 | equal | not-sent || |
	|IPv6 LAiid |::1000 | equal | not-sent || |		|IPv6 APPiid |::1000 | equal | not-sent || |
	+================+=========+========+=============++======+		+================+=========+========+=============++======+
	|UDP ESport |5683 | equal | not-sent || |		|UDP DEVport |5683 | equal | not-sent || |
	|UDP LAport |5683 | equal | not-sent || |		|UDP APPport |5683 | equal | not-sent || |
	|UDP Length | | ignore | comp-length || |		|UDP Length | | ignore | comp-length || |
	|UDP checksum | | ignore | comp-chk || |		|UDP checksum | | ignore | comp-chk || |
	+================+=========+========+=============++======+		+================+=========+========+=============++======+
	Rule 2		Rule 2
	+----------------+---------+--------+-------------++------+		+----------------+---------+--------+-------------++------+
	| Field | Value | Match | Function || Sent |		| Field | Value | Match | Function || Sent |
	+----------------+---------+--------+-------------++------+		+----------------+---------+--------+-------------++------+
	|IPv6 version |6 | equal | not-sent || |		|IPv6 version |6 | equal | not-sent || |
	|IPv6 DiffServ |0 | equal | not-sent || |		|IPv6 DiffServ |0 | equal | not-sent || |
	|IPv6 Flow Label |0 | equal | not-sent || |		|IPv6 Flow Label |0 | equal | not-sent || |
	|IPv6 Length | | ignore | comp-IPv6-l || |		|IPv6 Length | | ignore | comp-length || |
	|IPv6 Next Header|17 | equal | not-sent || |		|IPv6 Next Header|17 | equal | not-sent || |
	|IPv6 Hop Limit |255 | ignore | not-sent || |		|IPv6 Hop Limit |255 | ignore | not-sent || |
	|IPv6 ESprefix |alpha/64 | equal | not-sent || |		|IPv6 DEVprefix |alpha/64 | equal | not-sent || |
	|IPv6 ESiid | | ignore | ESiid-DID || |		|IPv6 DEViid | | ignore | DEViid-DID || |
	|IPv6 LAprefix |gamma/64 | equal | not-sent || |		|IPv6 APPprefix |gamma/64 | equal | not-sent || |
	|IPv6 LAiid |::1000 | equal | not-sent || |		|IPv6 APPiid |::1000 | equal | not-sent || |
	+================+=========+========+=============++======+		+================+=========+========+=============++======+
	|UDP ESport |8720 | MSB(12)| LSB(4) || lsb |		|UDP DEVport |8720 | MSB(12)| LSB(4) || lsb |
	|UDP LAport |8720 | MSB(12)| LSB(4) || lsb |		|UDP APPport |8720 | MSB(12)| LSB(4) || lsb |
	|UDP Length | | ignore | comp-length || |		|UDP Length | | ignore | comp-length || |
	|UDP checksum | | ignore | comp-chk || |		|UDP checksum | | ignore | comp-chk || |
	+================+=========+========+=============++======+		+================+=========+========+=============++======+
	Figure 5: Context rules		Figure 6: Context rules
	All the fields described in the three rules Figure 5 are present in		All the fields described in the three rules Figure 6 are present in
	the IPv6 and UDP headers. The ESDevice-ID value is found in the L2		the IPv6 and UDP headers. The DEViid-DID value is found in the L2
	header.		header.
	The second and third rules use global addresses. The way the ES		The second and third rules use global addresses. The way the DEV
	learns the prefix is not in the scope of the document.		learns the prefix is not in the scope of the document.
	The third rule compresses port numbers to 4 bits.		The third rule compresses port numbers to 4 bits.
	8. Fragmentation		8. Fragmentation
	8.1. Overview		8.1. Overview
	Fragmentation support in LPWAN is mandatory and it is used if, after		Fragmentation support in LPWAN is mandatory when the underlying LPWAN
	SCHC header compression, the size of the resulting packet is larger		technology is not capable of fulfilling the IPv6 MTU requirement.
	than the L2 data unit maximum payload. Fragmentation is also used if		Fragmentation is used if, after SCHC header compression, the size of
	SCHC header compression has not been able to compress a packet that		the resulting IPv6 packet is larger than the L2 data unit maximum
	is larger than the L2 data unit maximum payload. In LPWAN		payload. Fragmentation is also used if SCHC header compression has
	technologies the L2 data unit size typically varies from tens to		not been able to compress an IPv6 packet that is larger than the L2
	hundreds of bytes. If the entire IPv6 datagram fits within a single		data unit maximum payload. In LPWAN technologies, the L2 data unit
	L2 data unit, the fragmentation mechanism is not used and the packet		size typically varies from tens to hundreds of bytes. If the entire
	is sent unfragmented.		IPv6 datagram fits within a single L2 data unit, the fragmentation
			mechanism is not used and the packet is sent unfragmented.
	If the datagram does not fit within a single L2 data unit, it SHALL		If the datagram does not fit within a single L2 data unit, it SHALL
	be broken into fragments.		be broken into fragments.
	Moreover, LPWAN technologies impose some strict limitations on		Moreover, LPWAN technologies impose some strict limitations on
	traffic; therefore it is desirable to enable optional fragment		traffic; therefore it is desirable to enable optional fragment
	retransmission, while a single fragment loss should not lead to		retransmission, while a single fragment loss should not lead to
	retransmitting the full datagram. To preserve energy, Things (End		retransmitting the full IPv6 datagram. On the other hand, in order
	Systems) are sleeping most of the time and may receive data during a		to preserve energy, Things (End Systems) are sleeping most of the
	short period of time after transmission.		time and may receive data during a short period of time after
			transmission. In order to adapt to the capabilities of various LPWAN
			technologies, this specification allows for a gradation of fragment
			delivery reliability. This document does not make any decision with
			regard to which fragment delivery reliability option is used over a
			specific LPWAN technology.
	In order to adapt to the capabilities of various LPWAN technologies,		An important consideration is that LPWAN networks typically follow
	this specification allows for a gradation of fragment delivery		the star topology, and therefore data unit reordering is not expected
	reliability. There are three main options: Unreliable (UnR) mode,		in such networks. This specification assumes that reordering will
	Reliable per-Packet (RpP) mode and Reliable per-Window (RpW) mode.		not happen between the entity performing fragmentation and the entity
	Additionally, the specification provides the option to withhold		performing reassembly. This assumption allows to reduce complexity
	acknowledgments (ACK) in case of success, making effectively the ACK		and overhead of the fragmentation mechanism.
	a Negative ACK (NACK). It is up to the underlying LPWAN technology
	to decide which setting to use and whether the same setting applies		8.2. Reliability options: definition
	to all IPv6 packets. Note that the fragment delivery reliability
	option to be used is not necessarily tied to the particular		This specification defines the following five fragment delivery
	characteristics of the underlying L2 LPWAN technology (e.g. UnR may		reliability options:
	be used on top of an L2 LPWAN technology with symmetric
	characteristics for uplink and downlink).		o No ACK
			o Packet mode - ACK "always"
			o Packet mode - ACK on error
			o Window mode - ACK "always"
			o Window mode - ACK on error
	The same reliability option MUST be used for all fragments of a		The same reliability option MUST be used for all fragments of a
	packet.		packet. It is up to the underlying LPWAN technology to decide which
			reliability option to use and whether the same reliability option
			applies to all IPv6 packets. Note that the reliability option to be
			used is not necessarily tied to the particular characteristics of the
			underlying L2 LPWAN technology (e.g. a reliability option without
			receiver feedback may be used on top of an L2 LPWAN technology with
			symmetric characteristics for uplink and downlink).
	In UnR mode, the receiver MUST NOT issue acknowledgments. In RpP		In the No ACK option, the receiver MUST NOT issue acknowledgments
	mode, the receiver may transmit one acknowledgment (ACK) after all		(ACK).
	fragments carrying an IPv6 packet have been transmitted. The ACK
	informs the sender about received and missing fragments from the IPv6		In Packet mode - ACK "always", the receiver transmits one ACK after
	packet. In RpW mode, an ACK may be transmitted by the fragment		all fragments carrying an IPv6 packet have been transmitted. The ACK
			informs the sender about received and/or missing fragments from the
			IPv6 packet.
			In Packet mode - ACK on error, the receiver transmits one ACK after
			all fragments carrying an IPv6 packet have been transmitted, only if
			at least one of those fragments has been lost. The ACK informs the
			sender about received and/or missing fragments from the IPv6 packet.
			In Window mode - ACK "always", an ACK is transmitted by the fragment
	receiver after a window of fragments have been sent. A window of		receiver after a window of fragments have been sent. A window of
	fragments is a subset of the full set of fragments needed to carry an		fragments is a subset of the full set of fragments needed to carry an
	IPv6 packet. In this mode, the ACK informs the sender about received		IPv6 packet. In this mode, the ACK informs the sender about received
	and missing fragments from the window of fragments. In either mode,		and/or missing fragments from the window of fragments.
	upon receipt of an ACK that informs about any lost fragments, the
	sender may retransmit the lost fragments. The maximum number of ACK
	and retransmission rounds is TBD.
	Some LPWAN deployments may benefit from conditioning the creation and		In Window mode - ACK on error, an ACK is transmitted by the fragment
	transmission of an ACK to the detection of at least one fragment loss		receiver after a window of fragments have been sent, only if at least
	(per-packet or per-window), thus leading to NACK-oriented behavior,		one of the fragments in the window has been lost. In this mode, the
	while not having such condition may be preferred for other scenarios.		ACK informs the sender about received and/or missing fragments from
			the window of fragments.
	This document does not make any decision as to whether UnR, RpP or		In Packet or Window mode, upon receipt of an ACK that informs about
	RpW modes are used, or or whether the transmission of ACKs is		any lost fragments, the sender retransmits the lost fragments, up to
	conditioned to the detection of fragment losses or not. A complete		a maximum number of ACK and retransmission rounds that is TBD.
	specification of the receiver and sender behaviors that correspond to
	each acknowledgment policy is also out of scope. Nevertheless, this
	document does provide examples of the different reliability options
	described.
	8.2. Fragment format		This document does not make any decision as to which fragment
			delivery reliability option(s) need to be supported over a specific
			LPWAN technology.
			Examples of the different reliability options described are provided
			in Appendix A.
			8.3. Reliability options: discussion
			This section discusses the properties of each fragment delivery
			reliability option defined in the previous section. Figure Figure 7
			summarizes advantages and disadvantages of the reliability options
			that provide receiver feedback.
			No ACK is the most simple fragment delivery reliability option. With
			this option, the receiver does not generate overhead in the form of
			ACKs. However, this option does not enhance delivery reliability
			beyond that offered by the underlying LPWAN technology.
			ACK on error options are based on the optimistic expectation that the
			underlying links will offer relatively low L2 data unit loss
			probability. ACK on error reduces the number of ACKs transmitted by
			the fragment receiver compared to ACK "always" options. This may be
			especially beneficial in asymmetric scenarios, e.g. where fragmented
			data are sent uplink and the underlying LPWAN technology downlink
			capacity or message rate is lower than the uplink one.
			The Packet mode - ACK on error option provides reliability with low
			ACK overhead. However, if an ACK is lost, the sender assumes that
			all fragments carrying the IPv6 datagram have been successfully
			delivered. In contrast, the Packet mode - ACK "always" option does
			not suffer that issue, at the expense of a moderate ACK overhead. An
			issue with any of the Packet modes is that detection of a long burst
			of lost frames is only possible after relatively long time (i.e. at
			the end of the transmission of all fragments carrying an IPv6
			datagram).
			In contrast with Packet modes, the Window mode - ACK "always" option
			provides flow control. In addition, it is able to better handle long
			bursts of lost fragments, since detection of such events can be done
			earlier than with any of the Packet modes. However, the benefits of
			Window mode - ACK "always" come at the expense of higher ACK
			overhead.
			With regard to the Window mode - ACK on error option, there is no
			known use case for it at the time of the writing.
			+-----------------------+------------------------+
			| Packet mode | Window mode |
			+-----------------+-----------------------+------------------------+
			| | + Low ACK overhead | |
			| ACK on error | - Long loss burst | (Use case unknown) |
			| | - No flow control | |
			+-----------------+-----------------------+------------------------+
			| | + Moderate ACK overh. | + Flow control |
			| ACK "always" | - Long loss burst | + Long loss burst |
			| | - No flow control | - Higher ACK overhead |
			+-----------------+-----------------------+------------------------+
			Figure 7: Summary of fragment delivery options that provide receiver
			feedback, and their main advantages (+) and disadvantages (-).
			8.4. Fragment format
	A fragment comprises a fragmentation header and a fragment payload,		A fragment comprises a fragmentation header and a fragment payload,
	and conforms to the format shown in Figure 6. The fragment payload		and conforms to the format shown in Figure 8. The fragment payload
	carries a subset of either the IPv6 packet after header compression		carries a subset of either the IPv6 packet after header compression
	or an IPv6 packet which could not be compressed. A fragment is the		or an IPv6 packet which could not be compressed. A fragment is the
	payload in the L2 protocol data unit (PDU).		payload in the L2 protocol data unit (PDU).
	+---------------+-----------------------+		+---------------+-----------------------+
	| Fragm. Header | Fragment payload |		| Fragm. Header | Fragment payload |
	+---------------+-----------------------+		+---------------+-----------------------+
	Figure 6: Fragment format.		Figure 8: Fragment format.
	8.3. Fragmentation header formats		8.5. Fragmentation header formats
	Fragments except the last one SHALL		In any of the Window modes, fragments except the last one SHALL
	contain the fragmentation header as defined in Figure 7. The total		contain the fragmentation header as defined in Figure 9. The total
	size of this fragmentation header is R bits.		size of this fragmentation header is R bits.
	<----------- R ----------->		<------------ R ---------->
	<-- N -->		<--T--> 1 <--N-->
	+----- ... -----+-- ... --+		+-- ... --+- ... -+-+- ... -+
	| Rule ID | CFN |		| Rule ID | DTag |W| CFN |
	+----- ... -----+-- ... --+		+-- ... --+- ... -+-+- ... -+
	Figure 7: Fragmentation Header for Fragments except the Last One		Figure 9: Fragmentation Header for Fragments except the Last One,
			Window mode
	The last fragment SHALL contain a fragmentation header that conforms		In any of the Packet modes, fragments (except the last one) that are
	to the format shown in Figure 8. The total size of this		transmitted for the first time SHALL contain the fragmentation header
	fragmentation header is R+M bits.		shown in Figure 10. The total size of this fragmentation header is R
			bits.
	<----------- R ---------->		<------------- R ------------>
	<-- N --> <---- M ----->		<- T -> <- N ->
	+----- ... -----+-- ... --+---- ... ----+		+---- ... ---+- ... -+- ... -+
	| Rule ID | 11..1 | MIC |		| Rule ID | DTag | CFN |
	+----- ... -----+-- ... --+---- ... ----+		+---- ... ---+- ... -+- ... -+
	Figure 8: Fragmentation Header for the Last Fragment		Figure 10: Fragmentation Header for Fragments except the Last One, in
			a Packet mode; first transmission attempt
	Rule ID: this field has a size of R - N bits in all fragments. Rule		In any of the Packet modes, fragments (except the last one) that are
	ID may be used to signal whether UnR, RpP or RpW mode is in use, and		retransmitted SHALL
	within the latter, whether window mode or packet mode are used.		contain the fragmentation header as defined in Figure 11.
	CFN: CFN stands for Compressed Fragment Number. The size of the CFN		<------------- R ------------>
	field is N bits. In UnR mode, N=1. For RpP or RpW modes, N equal to		<- T -> <----- A ---->
	or greater than 3 is recommended. This field is an unsigned integer		+---- ... ---+- ... -+----- ... ----+
	that carries a non-absolute fragment number. The CFN MUST be set		| Rule ID | DTag | AFN |
	sequentially decreasing from 2^N - 2 for the first fragment, and MUST		+---- ... ---+- ... -+----- ... ----+
	wrap from 0 back to 2^N - 2 (e.g. for N=3, the first fragment has
	CFN=6, subsequent CFNs are set sequentially and in decreasing order,
	and CFN will wrap from 0 back to 6). The CFN for the last fragment
	has all bits set to 1. Note that, by this definition, the CFN value
	of 2^N - 1 is only used to identify a fragment as the last fragment
	carrying a subset of the IPv6 packet being transported, and thus the
	CFN does not strictly correspond to the N least significant bits of
	the actual absolute fragment number. It is also important to note
	that, for N=1, the last fragment of the packet will carry a CFN equal
	to 1, while all previous fragments will carry a CFN of 0.
	MIC: MIC stands for Message Integrity Check. This field has a size		Figure 11: Fragmentation Header for Retransmitted Fragments (Except
	of M bits. It is computed by the sender over the complete IPv6		the Last One) in a Packet mode
	packet before fragmentation by using the TBD algorithm. The MIC
	allows to check for errors in the reassembled IPv6 packet, while it
	also enables compressing the UDP checksum by use of SCHC.
	The values for R, N and M are not specified in this document, and		The last fragment of an IPv6 datagram, regardless of whether a Packet
	have to be determined by the underlying LPWAN technology.		mode or Window mode is in use, SHALL contain a fragmentation header
			that conforms to the format shown in Figure 12. The total size of
			this fragmentation header is R+M bits.
	8.4. ACK format		<------------- R ------------>
			<- T -> <- N -> <---- M ----->
			+---- ... ---+- ... -+- ... -+---- ... ----+
			| Rule ID | DTag | 11..1 | MIC |
			+---- ... ---+- ... -+- ... -+---- ... ----+
	The format of an ACK is shown in Figure 9:		Figure 12: Fragmentation Header for the Last Fragment
	<----- R ---->		o Rule ID: this field has a size of R - T - N - 1 bits in all
	+-+-+-+-+-+-+-+-+----- ... ---+		fragments that are not the last one, when Window mode is used. In
	| Rule ID | bitmap |		all other fragments, the Rule ID field has a size of R - T - N
	+-+-+-+-+-+-+-+-+----- ... ---+		bits. The Rule ID in a fragment is set to a value that indicates
			that the data unit being carried is a fragment. This also allows
			to interleave non-fragmented IPv6 datagrams with fragments that
			carry a larger IPv6 datagram. Rule ID may be used to signal which
			reliability option is in use. In any of the Packet modes, Rule ID
			is also used to indicate whether the fragment is a first
			transmission or a retransmission.
	Figure 9: Format of an ACK		o DTag: DTag stands for Datagram Tag. The size of the DTag field is
			T bits, which may be set to a value greater than or equal to 0
			bits. The DTag field in all fragments that carry the same IPv6
			datagram MUST be set to the same value. The DTag field allows to
			interleave fragments that correspond to different IPv6 datagrams.
			DTag MUST be set sequentially increasing from 0 to 2^T - 1, and
			MUST wrap back from 2^T - 1 to 0.
			o CFN: CFN stands for Compressed Fragment Number. The size of the
			CFN field is N bits. In the No ACK option, N=1. For the rest of
			options,
			N equal to or greater than 3 is recommended. This field is an
			unsigned integer that carries a non-absolute fragment number. The
			CFN MUST be set sequentially decreasing from 2^N - 2 for the first
			fragment, and MUST wrap from 0 back to 2^N - 2 (e.g. for N=3, the
			first fragment has CFN=6, subsequent CFNs are set sequentially and
			in decreasing order, and CFN will wrap from 0 back to 6). The CFN
			for the last fragment has all bits set to 1. Note that, by this
			definition, the CFN value of 2^N - 1 is only used to identify a
			fragment as the last fragment carrying a subset of the IPv6 packet
			being transported, and thus the CFN does not strictly correspond
			to the N least significant bits of the actual absolute fragment
			number. It is also important to note that, for N=1, the last
			fragment of the packet will carry a CFN equal to 1, while all
			previous fragments will carry a CFN of 0.
			o W: W is a 1-bit flag that is used in Window mode. Its purpose is
			avoiding possible ambiguity for the receiver that might arise
			under certain conditions. This flag carries the same value for
			all fragments of a window, and it is set to the other value for
			the next window. The initial value for this flag is 1.
			o AFN: AFN stands for Absolute Fragment Number. This field has a
			size of A bits. 'A' may be greater than N. The AFN is an
			unsigned integer that carries the absolute fragment number that
			corresponds to a fragment from an IPv6 packet. The AFN MUST be
			set sequentially and in increasing order, starting from 0.
			o MIC: MIC stands for Message Integrity Check. This field has a
			size of M bits. It is computed by the sender over the complete
			IPv6 packet before fragmentation by using the TBD algorithm. The
			MIC allows to check for errors in the reassembled IPv6 packet,
			while it also enables compressing the UDP checksum by use of SCHC.
			The values for R, N, A and M are not specified in this document,
			and have to be determined by the underlying LPWAN technology.
			8.6. ACK format
			The format of an ACK is shown in Figure 13:
			<------- R ------>
			<- T ->
			+---- ... --+-... -+----- ... ---+
			| Rule ID | DTag | bitmap |
			+---- ... --+-... -+----- ... ---+
			Figure 13: Format of an ACK
	Rule ID: In all ACKs, Rule ID has a size of R bits and SHALL be set		Rule ID: In all ACKs, Rule ID has a size of R bits and SHALL be set
	to TBD_ACK to signal that the message is an ACK.		to TBD_ACK to signal that the message is an ACK.
			DTag: DTag has a size of T bits. DTag carries the same value as the
			DTag field in the fragments carrying the IPv6 datagram for which this
			ACK is intended.
	bitmap: size of the bitmap field of an ACK can be equal to 0 or		bitmap: size of the bitmap field of an ACK can be equal to 0 or
	Ceiling(Number_of_Fragments/8) octets, where Number_of_Fragments		Ceiling(Number_of_Fragments/8) octets, where Number_of_Fragments
	denotes the number of fragments of a window (in RpW mode) or the		denotes the number of fragments of a window (in Window mode) or the
	number of fragments that carry the IPv6 packet (in RpP mode). The		number of fragments that carry the IPv6 packet (in Packet mode). The
	bitmap is a sequence of bits, where the n-th bit signals whether the		bitmap is a sequence of bits, where the n-th bit signals whether the
	n-th fragment transmitted has been correctly received (n-th bit set		n-th fragment transmitted has been correctly received (n-th bit set
	to 1) or not (n-th bit set to 0). Remaining bits with bit order		to 1) or not (n-th bit set to 0). Remaining bits with bit order
	greater than the number of fragments sent (as determined by the		greater than the number of fragments sent (as determined by the
	receiver) are set to 0, except for the last bit in the bitmap, which		receiver) are set to 0, except for the last bit in the bitmap, which
	is set to 1 if the last fragment (carrying the MIC) has been		is set to 1 if the last fragment (carrying the MIC) has been
	correctly received, and 0 otherwise. Absence of the bitmap in an ACK		correctly received, and 0 otherwise. Absence of the bitmap in an ACK
	confirms correct reception of all fragments to be acknowledged by		confirms correct reception of all fragments to be acknowledged by
	means of the ACK.		means of the ACK.
	Figure 10 shows an example of an ACK in packet mode, where the bitmap		Figure 14 shows an example of an ACK in Packet mode, where the bitmap
	indicates that the second and the ninth fragments have not been		indicates that the second and the ninth fragments have not been
	correctly received. In this example, the IPv6 packet is carried by		correctly received. In this example, the IPv6 packet is carried by
	eleven fragments in total, therefore the bitmap has a size of two		eleven fragments in total, therefore the bitmap has a size of two
	bytes.		bytes.
	1		<------ R ------> 1
	<----- R ----> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		<- T -> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Rule ID |1|0|1|1|1|1|1|1|0|1|1|0|0|0|0|1|		| Rule ID | DTag |1|0|1|1|1|1|1|1|0|1|1|0|0|0|0|1|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 10: Example of the Bitmap in an ACK		Figure 14: Example of the Bitmap in an ACK
	Figure 11 shows an example of an ACK in RpW (N=3), where the bitmap		Figure 15 shows an example of an ACK in Window mode (N=3), where the
	indicates that the second and the fifth fragments have not been		bitmap indicates that the second and the fifth fragments have not
	correctly received.		been correctly received.
	<----- R ----> 0 1 2 3 4 5 6 7		<------ R ------>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		<- T -> 0 1 2 3 4 5 6 7
	| Rule ID |1|0|1|1|0|1|1|1|		+---- ... --+-... -+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| Rule ID | DTag |1|0|1|1|0|1|1|1|
			+---- ... --+-... -+-+-+-+-+-+-+-+-+
	Figure 11: Example of the bitmap in an ACK (in RpW mode, for N=3)		Figure 15: Example of the bitmap in an ACK (in Window mode, for N=3)
	Figure 12 illustrates an ACK without bitmap.		Figure 16 illustrates an ACK without bitmap.
	<----- R ---->		<------ R ------>
	+-+-+-+-+-+-+-+-+		<- T ->
	| Rule ID |		+---- ... --+-... -+
	+-+-+-+-+-+-+-+-+		| Rule ID | DTag |
			+---- ... --+-... -+
	Figure 12: Example of an ACK without bitmap		Figure 16: Example of an ACK without bitmap
	8.5. Baseline mechanism		8.7. Baseline mechanism
	The receiver of link fragments SHALL use (1) the sender's L2 source		The receiver of link fragments SHALL use (1) the sender's L2 source
	address (if present), (2) the destination's L2 address (if present),		address (if present), (2) the destination's L2 address (if present),
	and (3) Rule ID to identify all the fragments that belong to a given		(3) Rule ID and (4) DTag to identify all the fragments that belong to
	datagram. The fragment receiver SHALL determine the fragment		a Given IPv6 datagram. The fragment receiver may determine the
	delivery reliability option in use for the fragment based on the Rule		fragment delivery reliability option in use for the fragment based on
	ID field in that fragment.		the Rule ID field in that fragment.
	Upon receipt of a link fragment, the receiver starts constructing the		Upon receipt of a link fragment, the receiver starts constructing the
	original unfragmented packet. It uses the CFN and the order of		original unfragmented packet. It uses the CFN and the order of
	arrival of each fragment to determine the location of the individual		arrival of each fragment to determine the location of the individual
	fragments within the original unfragmented packet. For example, it		fragments within the original unfragmented packet. For example, it
	may place the data payload of the fragments within a payload datagram		may place the data payload of the fragments within a payload datagram
	reassembly buffer at the location determined from the CFN and order		reassembly buffer at the location determined from the CFN and order
	of arrival of the fragments, and the fragment payload sizes. Note		of arrival of the fragments, and the fragment payload sizes. In
	that the size of the original, unfragmented IPv6 packet cannot be		Window mode, the fragment receiver also uses the W flag in the
	determined from fragmentation headers.		received fragments. Note that the size of the original, unfragmented
			IPv6 packet cannot be determined from fragmentation headers.
	In RpW mode, when a fragment with all CFN bits set to 0 is received,		When ACK on error is used (for either Packet mode or Window mode),
	the recipient MAY transmit an ACK for the last window of fragments		the fragment receiver starts a timer (denoted "ACK on Error Timer")
	sent. Note that the first fragment of the window is the one sent		upon reception of the first fragment for an IPv6 datagram. The
	with CFN=2^N-2. In RpW mode, the fragment with CFN=0 is considered		initial value for this timer is not provided by this specification,
	the last fragment of its window, except for the last fragment of the		and is expected to be defined in additional documents. This timer is
	whole packet (with all CFN bits set to 1), which is also the last		reset every time that a new fragment carrying data from the same IPv6
	fragment of the last window.		datagram is received. In Packet mode - ACK on error, upon timer
			expiration, if the last fragment of the IPv6 datagram (i.e. carrying
			all CFN bits set to 1) has not been received, an ACK MUST be
			transmitted by the fragment receiver to indicate received and not
			received fragments for that IPv6 datagram.
			In Window mode - ACK on error, upon timer expiration, if neither the
			last fragment of the IPv6 datagram nor the last fragment of the
			current window (with CFN=0) have been received, an ACK MUST be
			transmitted by the fragment receiver to indicate received and not
			received fragments for the current window.
	Once the recipient has received the last fragment, it checks for the		Note that, in Window mode, the first fragment of the window is the
	integrity of the reassembled IPv6 datagram, based on the MIC		one sent with CFN=2^N-2. Also note that, in Window mode, the
	received. In UnR mode, if the integrity check indicates that the		fragment with CFN=0 is considered the last fragment of its window,
	reassembled IPv6 datagram does not match the original IPv6 datagram		except for the last fragment of the whole packet (with all CFN bits
	(prior to fragmentation), the reassembled IPv6 datagram MUST be		set to 1), which is also the last fragment of the last window. Upon
	discarded. In RpP or in RpW mode, upon receipt of the last fragment		receipt of the last fragment of a window, if Window mode - ACK
	(i.e. with all CFN bits set to 1), the recipient MAY transmit an ACK		"Always" is used, the fragment receiver MUST send an ACK to the
	for the whole set of fragments sent that carry the complete IPv6		fragment sender. The ACK provides feedback on the fragments received
	packet.		and lost that correspond to the last window.
	In RpP mode or in RpW mode, the sender retransmits any lost fragments		If the recipient receives the last fragment of an IPv6 datagram, it
	reported in the ACK. A maximum of TBD iterations of ACK and fragment		checks for the integrity of the reassembled IPv6 datagram, based on
	retransmission rounds are allowed per-window or per-IPv6-packet in		the MIC received. In No ACK mode, if the integrity check indicates
	RpP mode or in RpW mode, respectively. A complete specification of		that the reassembled IPv6 datagram does not match the original IPv6
	the mechanisms needed to enable the above described fragment delivery		datagram (prior to fragmentation), the reassembled IPv6 datagram MUST
	reliability options is out of the scope of this document.		be discarded. If ACK "Always" is used, the recipient MUST transmit
			an ACK to the fragment sender. The ACK
			provides feedback on the whole set of fragments sent that carry the
			complete IPv6 packet (Packet mode) or on the fragments that
			correspond to the last window (Window mode). If ACK on error is
			used, the recipient MUST NOT transmit an ACK to the sender if no
			losses have been detected for the whole IPv6 packet (Packet mode) or
			in the last window (Window mode). If losses have been detected, the
			recipient MUST then transmit an ACK to the sender to provide feedback
			on the whole IPv6 packet (Packet mode) or in the last window (Window
			mode).
			When ACK "Always" is used (in either Packet mode or Window mode), the
			fragment sender starts a timer (denoted "ACK Always Timer") after
			transmitting the last fragment of a fragmented IPv6 datagram. The
			initial value for this timer is not provided by this specification,
			and is expected to be defined in additional documents. Upon
			expiration of the timer, if no ACK has been received for this IPv6
			datagram, the sender retransmits the last fragment, and it
			reinitializes and restarts the timer. In Window mode - ACK "Always",
			the fragment sender also starts the ACK Always Timer after
			transmitting the last fragment of a window. Upon expiration of the
			timer, if no ACK has been received for this window, the sender
			retransmits the last fragment, and it reinitializes and restarts the
			timer. Note that retransmitting the last fragment of a packet or a
			window as described serves as an ACK request. The maximum number of
			ACK requests in Packet mode or in Window mode is TBD.
			In all reliability options, except for the No ACK option, the
			fragment sender retransmits any lost fragments reported in an ACK.
			In Packet modes, in order to minimize the probability of ambiguity
			with the CFN of different retransmitted fragments, the fragment
			sender
			renumbers the CFNs of the fragments to be retransmitted by following
			the same approach as for a sequence of new fragments: the CFN for
			retransmitted fragments is set sequentially decreasing from 2^N - 2
			for the first fragment, and MUST wrap from 0 back to 2^N - 2.
			However, the last fragment of the set of retransmitted fragments only
			carries a CFN with all bits set to 1 if it is actually a
			retransmission of the last fragment of the packet (i.e. the last
			fragment had been lost in the first place). Examples of fragment
			renumbering for retransmitted fragments in Packet modes can be found
			in Appendix A.
			A maximum of TBD iterations of ACK and fragment retransmission rounds
			are allowed per-window or per-IPv6-packet in Window mode or in Packet
			mode, respectively.
	If a fragment recipient disassociates from its L2 network, the		If a fragment recipient disassociates from its L2 network, the
	recipient MUST discard all link fragments of all partially		recipient MUST discard all link fragments of all partially
	reassembled payload datagrams, and fragment senders MUST discard all		reassembled payload datagrams, and fragment senders MUST discard all
	not yet transmitted link fragments of all partially transmitted		not yet transmitted link fragments of all partially transmitted
	payload (e.g., IPv6) datagrams. Similarly, when a node first		payload (e.g., IPv6) datagrams. Similarly, when a node first
	receives a fragment of a packet, it starts a reassembly timer. When		receives a fragment of a packet, it starts a reassembly timer. When
	this time expires, if the entire packet has not been reassembled, the		this time expires, if the entire packet has not been reassembled, the
	existing fragments MUST be discarded and the reassembly state MUST be		existing fragments MUST be discarded and the reassembly state MUST be
	flushed. The reassembly timeout MUST be set to a maximum of TBD		flushed. The value for this timer is not provided by this
	seconds).		specification, and is expected to be defined in technology-specific
			profile documents.
			8.8. Aborting a fragmented IPv6 datagram transmission
			For several reasons, a fragment sender or a fragment receiver may
			want to abort the transmission of a fragmented IPv6 datagram.
			If the fragment sender triggers abortion, it transmits to the
			receiver a format equivalent to a fragmentation header (with the
			format for a fragment that is not the last one), with the Rule ID
			field (of size R - T - N bits) set to TBD_ABORT_TX and all CFN bits
			set to 1. No data is carried along with this fragmentation header.
			If the fragment receiver triggers abortion, it transmits to the
			fragment sender a Rule ID (of size R bits) set to TBD_ABORT_RX. The
			entity that triggers abortion (either a fragment sender or a fragment
			receiver) MUST release any resources allocated for the fragmented
			IPv6 datagram transmission being aborted.
			When a fragment receiver receives an L2 frame containing a Rule ID
			set to TBD ABORT_TX and a CFN field with all bits set to 1, the
			receiver MUST release any resources allocated for the fragmented IPv6
			datagram transmission being aborted.
			When a fragment sender receives an L2 frame containing a Rule ID set
			to TBD_ABORT_RX, the fragment sender MUST abort transmission of the
			fragmented IPv6 datagram being transmitted, and MUST release any
			resources allocated for the fragmented IPv6 datagram transmission
			being aborted.
			A further Rule ID value may be used by an entity to signal abortion
			of all on- going, possibly interleaved, fragmented IPv6 datagram
			transmissions.
			8.9. Downlink fragment transmission
			In some LPWAN technologies, as part of energy-saving techniques,
			downlink transmission is only possible immediately after an uplink
			transmission. In order to avoid potentially high delay for
			fragmented IPv6 datagram transmission in the downlink, the fragment
			receiver MAY perform an uplink transmission as soon as possible after
			reception of a fragment that is not the last one. Such uplink
			transmission may be triggered by the L2 (e.g. an L2 ACK sent in
			response to a fragment encapsulated in a L2 frame that requires an L2
			ACK) or it may be triggered from an upper layer.
	9. Security considerations		9. Security considerations
	9.1. Security considerations for header compression		9.1. Security considerations for header compression
	TBD		TBD
	9.2. Security considerations for fragmentation		9.2. Security considerations for fragmentation
	This subsection describes potential attacks to LPWAN fragmentation		This subsection describes potential attacks to LPWAN fragmentation
	skipping to change at page 22, line 47 ¶		skipping to change at page 30, line 12 ¶
	functionality. The aim of this technique is to allow a receiver to		functionality. The aim of this technique is to allow a receiver to
	identify illegitimate fragments.		identify illegitimate fragments.
	Further attacks may involve sending overlapped fragments (i.e.		Further attacks may involve sending overlapped fragments (i.e.
	comprising some overlapping parts of the original IPv6 datagram).		comprising some overlapping parts of the original IPv6 datagram).
	Implementers should make sure that correct operation is not affected		Implementers should make sure that correct operation is not affected
	by such event.		by such event.
	10. Acknowledgements		10. Acknowledgements
	Thanks to Dominique Barthel, Carsten Bormann, Arunprabhu Kandasamy,		Thanks to Dominique Barthel, Carsten Bormann, Philippe Clavier,
	Antony Markovski, Alexander Pelov, Pascal Thubert, Juan Carlos Zuniga		Arunprabhu Kandasamy, Antony Markovski, Alexander Pelov, Pascal
	for useful design consideration.		Thubert, Juan Carlos Zuniga for useful design consideration.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,		(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <http://www.rfc-editor.org/info/rfc2460>.		December 1998, <http://www.rfc-editor.org/info/rfc2460>.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	skipping to change at page 23, line 34 ¶		skipping to change at page 30, line 45 ¶
	[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.
	Appendix A. Fragmentation examples		Appendix A. Fragmentation examples
	This section provides examples of different fragment delivery		This section provides examples of different fragment delivery
	reliability options possible on the basis of this specification.		reliability options possible on the basis of this specification.
	Figure 13 illustrates the transmission of an IPv6 packet that needs		Figure 17 illustrates the transmission of an IPv6 packet that needs
	11 fragments in UnR mode.		11 fragments in the No ACK option.
	Sender Receiver		Sender Receiver
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=1-------->|MIC checked =>		|-------CFN=1-------->|MIC checked =>
	Figure 13: Transmission of an IPv6 packet carried by 11 fragments in		Figure 17: Transmission of an IPv6 packet carried by 11 fragments in
	UnR mode		the No ACK option
	Figure 14 illustrates the transmission of an IPv6 packet that needs		Figure 18 illustrates the transmission of an IPv6 packet that needs
	11 fragments in RpP mode, for N=3, NACK-oriented, without losses.		11 fragments in Packet mode - ACK on error, for N=3, without losses.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=3-------->|		|-------CFN=3-------->|
	|-------CFN=2-------->|		|-------CFN=2-------->|
	|-------CFN=1-------->|		|-------CFN=1-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=7-------->|MIC checked =>		|-------CFN=7-------->|MIC checked =>
	(no NACK)		(no ACK)
	Figure 14: Transmission of an IPv6 packet carried by 11 fragments in		Figure 18: Transmission of an IPv6 packet carried by 11 fragments in
	RpP mode, for N=3, NACK-oriented; no losses.		Packet mode - ACK on error, for N=3, no losses.
	Figure 15 illustrates the transmission of an IPv6 packet that needs		Figure 19 illustrates the transmission of an IPv6 packet that needs
	11 fragments in RpP mode, for N=3, NACK-oriented, with three losses.		11 fragments in Packet mode - ACK on error, for N=3, with three
			losses.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		(AFN=0) |-------CFN=6-------->|
	|-------CFN=5-------->|		(AFN=1) |-------CFN=5-------->|
	|-------CFN=4---X---->|		(AFN=2) |-------CFN=4---X---->|
	|-------CFN=3-------->|		(AFN=3) |-------CFN=3-------->|
	|-------CFN=2---X---->|		(AFN=4) |-------CFN=2---X---->|
	|-------CFN=1-------->|		(AFN=5) |-------CFN=1-------->|
	|-------CFN=0-------->|		(AFN=6) |-------CFN=0-------->|
	|-------CFN=6-------->|		(AFN=7) |-------CFN=6-------->|
	|-------CFN=5-------->|		(AFN=8) |-------CFN=5-------->|
	|-------CFN=4---X---->|		(AFN=9) |-------CFN=4---X---->|
	|-------CFN=7-------->|MIC checked =>		|-------CFN=7-------->|MIC checked
	|<-------NACK---------|Bitmap:1101011110100001		|<-------ACK----------|Bitmap:1101011110100001
	|-------CFN=4-------->|		|-------AFN=2-------->|
	|-------CFN=2-------->|		|-------AFN=4-------->|
	|-------CFN=4-------->|MIC checked =>		|-------AFN=9-------->|MIC checked =>
	(no NACK)		(no ACK)
	Figure 15: Transmission of an IPv6 packet carried by 11 fragments in		Figure 19: Transmission of an IPv6 packet carried by 11 fragments in
	RpP mode, for N=3, NACK-oriented; three losses.		Packet mode - ACK on error, for N=3, three losses. In the figure,
			(AFN=x) indicates the AFN value computed by the sender for each
			fragment.
	Figure 16 illustrates the transmission of an IPv6 packet that needs		Figure 20 illustrates the transmission of an IPv6 packet that needs
	11 fragments in RpW mode, for N=3, without losses. Receiver feedback		11 fragments in Window mode - ACK on error, for N=3, without losses.
	is NACK-oriented. Note: in RpW mode, an additional bit will be
	needed to number windows.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-----W=1, CFN=6----->|
	|-------CFN=5-------->|		|-----W=1, CFN=5----->|
	|-------CFN=4-------->|		|-----W=1, CFN=4----->|
	|-------CFN=3-------->|		|-----W=1, CFN=3----->|
	|-------CFN=2-------->|		|-----W=1, CFN=2----->|
	|-------CFN=1-------->|		|-----W=1, CFN=1----->|
	|-------CFN=0-------->|		|-----W=1, CFN=0----->|
	(no NACK)		(no ACK)
	|-------CFN=6-------->|		|-----W=0, CFN=6----->|
	|-------CFN=5-------->|		|-----W=0, CFN=5----->|
	|-------CFN=4-------->|		|-----W=0, CFN=4----->|
	|-------CFN=7-------->|MIC checked =>		|-----W=0, CFN=7----->|MIC checked =>
	(no NACK)		(no ACK)
	Figure 16: Transmission of an IPv6 packet carried by 11 fragments in		Figure 20: Transmission of an IPv6 packet carried by 11 fragments in
	RpW mode, for N=3, NACK-oriented; without losses.		Window mode - ACK on error, for N=3, without losses.
	Figure 17 illustrates the transmission of an IPv6 packet that needs		Figure 21 illustrates the transmission of an IPv6 packet that needs
	11 fragments in RpW mode, for N=3, with three losses. Receiver		11 fragments in Window mode - ACK on error, for N=3, with three
	feedback is NACK-oriented. Note: in RpW mode, an additional bit will		losses.
	be needed to number windows.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-----W=1, CFN=6----->|
	|-------CFN=5-------->|		|-----W=1, CFN=5----->|
	|-------CFN=4---X---->|		|-----W=1, CFN=4--X-->|
	|-------CFN=3-------->|		|-----W=1, CFN=3----->|
	|-------CFN=2---X---->|		|-----W=1, CFN=2--X-->|
	|-------CFN=1-------->|		|-----W=1, CFN=1----->|
	|-------CFN=0-------->|		|-----W=1, CFN=0----->|
	|<-------NACK---------|Bitmap:11010111		|<-------ACK----------|Bitmap:11010111
	|-------CFN=4-------->|		|-----W=1, CFN=4----->|
	|-------CFN=2-------->|		|-----W=1, CFN=2----->|
	(no NACK)		(no ACK)
	|-------CFN=6-------->|		|-----W=0, CFN=6----->|
	|-------CFN=5-------->|		|-----W=0, CFN=5----->|
	|-------CFN=4---X---->|		|-----W=0, CFN=4--X-->|
	|-------CFN=7-------->|MIC checked =>		|-----W=0, CFN=7----->|MIC checked
	|<-------NACK---------|Bitmap:11010001		|<-------ACK----------|Bitmap:11010001
	|-------CFN=4-------->|MIC checked =>		|-----W=0, CFN=4----->|MIC checked =>
	(no NACK)		(no ACK)
	Figure 17: Transmission of an IPv6 packet carried by 11 fragments in		Figure 21: Transmission of an IPv6 packet carried by 11 fragments in
	RpW, for N=3, NACK-oriented; three losses.		Window mode - ACK on error, for N=3, three losses.
	Figure 18 illustrates the transmission of an IPv6 packet that needs		Figure 22 illustrates the transmission of an IPv6 packet that needs
	11 fragments in RpP mode, for N=3, without losses. Receiver feedback		11 fragments in Packet mode - ACK "Always", for N=3, without losses.
	is positive-ACK-oriented.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=3-------->|		|-------CFN=3-------->|
	|-------CFN=2-------->|		|-------CFN=2-------->|
	|-------CFN=1-------->|		|-------CFN=1-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=7-------->|MIC checked =>		|-------CFN=7-------->|MIC checked =>
	|<-------ACK----------|no bitmap		|<-------ACK----------|no bitmap
	(End)		(End)
	Figure 18: Transmission of an IPv6 packet carried by 11 fragments in		Figure 22: Transmission of an IPv6 packet carried by 11 fragments in
	RpP mode, for N=3, positive-ACK-oriented; no losses.		Packet mode - ACK "Always", for N=3, no losses.
	Figure 19 illustrates the transmission of an IPv6 packet that needs		Figure 23 illustrates the transmission of an IPv6 packet that needs
	11 fragments in RpP mode, for N=3, with three losses. Receiver		11 fragments in Packet mode - ACK "Always", for N=3, with three
	feedback is positive-ACK-oriented.		losses.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		(AFN=0) |-------CFN=6-------->|
	|-------CFN=5-------->|		(AFN=1) |-------CFN=5-------->|
	|-------CFN=4---X---->|		(AFN=2) |-------CFN=4---X---->|
	|-------CFN=3-------->|		(AFN=3) |-------CFN=3-------->|
	|-------CFN=2---X---->|		(AFN=4) |-------CFN=2---X---->|
	|-------CFN=1-------->|		(AFN=5) |-------CFN=1-------->|
	|-------CFN=0-------->|		(AFN=6) |-------CFN=0-------->|
	|-------CFN=6-------->|		(AFN=7) |-------CFN=6-------->|
	|-------CFN=5-------->|		(AFN=8) |-------CFN=5-------->|
	|-------CFN=4---X---->|		(AFN=9) |-------CFN=4---X---->|
	|-------CFN=7-------->|MIC checked =>		|-------CFN=7-------->|MIC checked
	|<-------ACK----------|bitmap:1101011110100001		|<-------ACK----------|bitmap:1101011110100001
	|-------CFN=4-------->|		|-------AFN=2-------->|
	|-------CFN=2-------->|		|-------AFN=4-------->|
	|-------CFN=4-------->|MIC checked =>		|-------AFN=9-------->|MIC checked =>
	|<-------ACK----------|no bitmap		|<-------ACK----------|no bitmap
	(End)		(End)
	Figure 19: Transmission of an IPv6 packet carried by 11 fragments in		Figure 23: Transmission of an IPv6 packet carried by 11 fragments in
	RpP, for N=3, positive-ACK-oriented; with three losses.		Packet mode - ACK "Always", for N=3, with three losses.
	Figure 20 illustrates the transmission of an IPv6 packet that needs		Figure 24 illustrates the transmission of an IPv6 packet that needs
	11 fragments in RpW mode, for N=3, without losses. Receiver feedback		11 fragments in Window mode - ACK "Always", for N=3, without losses.
	is positive-ACK-oriented. Note: in RpW mode, an additional bit will		Note: in Window mode, an additional bit will be needed to number
	be needed to number windows.		windows.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-----W=1, CFN=6----->|
	|-------CFN=5-------->|		|-----W=1, CFN=5----->|
	|-------CFN=4-------->|		|-----W=1, CFN=4----->|
	|-------CFN=3-------->|		|-----W=1, CFN=3----->|
	|-------CFN=2-------->|		|-----W=1, CFN=2----->|
	|-------CFN=1-------->|		|-----W=1, CFN=1----->|
	|-------CFN=0-------->|		|-----W=1, CFN=0----->|
	|<-------ACK----------|no bitmap		|<-------ACK----------|no bitmap
	|-------CFN=6-------->|		|-----W=0, CFN=6----->|
	|-------CFN=5-------->|		|-----W=0, CFN=5----->|
	|-------CFN=4-------->|		|-----W=0, CFN=4----->|
	|-------CFN=7-------->|MIC checked =>		|-----W=0, CFN=7----->|MIC checked =>
	|<-------ACK----------|no bitmap		|<-------ACK----------|no bitmap
	(End)		(End)
	Figure 20: Transmission of an IPv6 packet carried by 11 fragments in		Figure 24: Transmission of an IPv6 packet carried by 11 fragments in
	RpW mode, for N=3, positive-ACK-oriented; no losses.		Window mode - ACK "Always", for N=3, no losses.
	Figure 21 illustrates the transmission of an IPv6 packet that needs		Figure 25 illustrates the transmission of an IPv6 packet that needs
	11 fragments in RpW mode, for N=3, with three losses. Receiver		11 fragments in Window mode - ACK "Always", for N=3, with three
	feedback is positive-ACK-oriented. Note: in RpW mode, an additional		losses.
	bit will be needed to number windows.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-----W=1, CFN=6----->|
	|-------CFN=5-------->|		|-----W=1, CFN=5----->|
	|-------CFN=4---X---->|		|-----W=1, CFN=4--X-->|
	|-------CFN=3-------->|		|-----W=1, CFN=3----->|
	|-------CFN=2---X---->|		|-----W=1, CFN=2--X-->|
	|-------CFN=1-------->|		|-----W=1, CFN=1----->|
	|-------CFN=0-------->|		|-----W=1, CFN=0----->|
	|<-------ACK----------|bitmap:11010111		|<-------ACK----------|bitmap:11010111
	|-------CFN=4-------->|		|-----W=1, CFN=4----->|
	|-------CFN=2-------->|		|-----W=1, CFN=2----->|
	|<-------ACK----------|no bitmap		|<-------ACK----------|no bitmap
	|-------CFN=6-------->|		|-----W=0, CFN=6----->|
	|-------CFN=5-------->|		|-----W=0, CFN=5----->|
	|-------CFN=4---X---->|		|-----W=0, CFN=4--X-->|
	|-------CFN=7-------->|MIC checked =>		|-----W=0, CFN=7----->|MIC checked
	|<-------ACK----------|bitmap:11010001		|<-------ACK----------|bitmap:11010001
	|-------CFN=4-------->|MIC checked =>		|-----W=0, CFN=4----->|MIC checked =>
	|<-------ACK----------|no bitmap		|<-------ACK----------|no bitmap
	(End)		(End)
	Figure 21: Transmission of an IPv6 packet carried by 11 fragments in		Figure 25: Transmission of an IPv6 packet carried by 11 fragments in
	RpW mode, for N=3, positive-ACK-oriented; with three losses.		Window mode - ACK "Always", for N=3, with three losses.
	Appendix B. Note		Appendix B. Note
	Carles Gomez has been funded in part by the Spanish Government		Carles Gomez has been funded in part by the Spanish Government
	(Ministerio de Educacion, Cultura y Deporte) through the Jose		(Ministerio de Educacion, Cultura y Deporte) through the Jose
	Castillejo grant CAS15/00336, and by the ERDF and the Spanish		Castillejo grant CAS15/00336, and by the ERDF and the Spanish
	Government through project TEC2016-79988-P. Part of his contribution		Government through project TEC2016-79988-P. Part of his contribution
	to this work has been carried out during his stay as a visiting		to this work has been carried out during his stay as a visiting
	scholar at the Computer Laboratory of the University of Cambridge.		scholar at the Computer Laboratory of the University of Cambridge.
End of changes. 179 change blocks.
	520 lines changed or deleted		879 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/