< draft-ietf-lpwan-ipv6-static-context-hc-04.txt		draft-ietf-lpwan-ipv6-static-context-hc-05.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: December 18, 2017 IMT-Atlantique		Expires: January 2, 2018 IMT-Atlantique
	C. Gomez		C. Gomez
	Universitat Politecnica de Catalunya		Universitat Politecnica de Catalunya
	June 16, 2017		July 01, 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-04		draft-ietf-lpwan-ipv6-static-context-hc-05
	Abstract		Abstract
	This document describes a header compression scheme and fragmentation		This document describes a header compression scheme and fragmentation
	functionality for very low bandwidth networks. These techniques are		functionality for very low bandwidth networks. These techniques are
	especially tailored for LPWAN (Low Power Wide Area Network) networks.		especially tailored for LPWAN (Low Power Wide Area Network) networks.
	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 and must be used for		flexibility when processing the header fields and must be used for
	this kind of networks. A common context stored in a LPWAN device and		these kind of networks. A common context stored in a LPWAN device
	in the network is used. This context stores information that will		and in the network is used. This context keeps information that will
	not be transmitted in the constrained network. Static context means		not be transmitted in the constrained network. Static context means
	that information stored in the context which describes field values,		that information stored in the context which describes field values,
	does not change during packet transmission, avoiding complex		does not change during packet transmission, avoiding complex
	resynchronization mechanisms, incompatible with LPWAN		resynchronization mechanisms, incompatible with LPWAN
	characteristics. In most of the cases, IPv6/UDP headers are reduced		characteristics. In most of the cases, IPv6/UDP headers are reduced
	to a small identifier called Rule ID. But sometimes the SCHC header		to a small identifier called Rule ID. But sometimes the SCHC header
	compression will not be enough to send the packet in one L2 PDU, so		compression mechanisms will not be enough to send the compressed
	this document also describes a Fragmentation protocol that must be		packet in one L2 PDU, so the SCHC Fragmentation protocol must be used
	used when needed.		when needed.
	This document describes the generic compression/decompression		This document describes SCHC compression/decompression mechanism
	mechanism and applies it to IPv6/UDP headers. Similar mechanisms for		framework and applies it to IPv6/UDP headers. Similar solutions for
	other protocols such as CoAP will be described in separate documents.		other protocols such as CoAP will be described in separate documents.
	Moreover, this document specifies fragmentation and reassembly		Moreover, this document specifies fragmentation and reassembly
	mechanims for SCHC compressed packets exceeding the L2 PDU size and		mechanim for SCHC compressed packets exceeding the L2 PDU size and
	for the case where the SCHC compression is not possible then the		for the case where the SCHC compression is not possible then the
	IPv6/UDP packet is sent using the fragmentation protocol.		packet is sent using the fragmentation protocol.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 18, 2017.		This Internet-Draft will expire on January 2, 2018.
	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
	skipping to change at page 3, line 21 ¶		skipping to change at page 3, line 21 ¶
	7.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 18		7.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 18
	8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. IPv6/UDP compression . . . . . . . . . . . . . . . . . . 18		8.1. IPv6/UDP compression . . . . . . . . . . . . . . . . . . 18
	9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 21		9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 21
	9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21		9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21
	9.2. Reliability options: definition . . . . . . . . . . . . . 22		9.2. Reliability options: definition . . . . . . . . . . . . . 22
	9.3. Reliability options: discussion . . . . . . . . . . . . . 23		9.3. Reliability options: discussion . . . . . . . . . . . . . 23
	9.4. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 23		9.4. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	9.5. Formats . . . . . . . . . . . . . . . . . . . . . . . . . 24		9.5. Formats . . . . . . . . . . . . . . . . . . . . . . . . . 24
	9.5.1. Fragment format . . . . . . . . . . . . . . . . . . . 24		9.5.1. Fragment format . . . . . . . . . . . . . . . . . . . 24
	9.5.2. Fragmentation header formats . . . . . . . . . . . . 24		9.5.2. Fragmentation header formats . . . . . . . . . . . . 25
	9.5.3. ACK format . . . . . . . . . . . . . . . . . . . . . 26		9.5.3. ACK format . . . . . . . . . . . . . . . . . . . . . 27
	9.6. Baseline mechanism . . . . . . . . . . . . . . . . . . . 28		9.6. Baseline mechanism . . . . . . . . . . . . . . . . . . . 28
	9.7. Supporting multiple window sizes . . . . . . . . . . . . 29		9.7. Supporting multiple window sizes . . . . . . . . . . . . 31
	9.8. Aborting fragmented IPv6 datagram transmissions . . . . . 30		9.8. Aborting fragmented IPv6 datagram transmissions . . . . . 31
	9.9. Downlink fragment transmission . . . . . . . . . . . . . 30		9.9. Downlink fragment transmission . . . . . . . . . . . . . 31
	10. Security considerations . . . . . . . . . . . . . . . . . . . 30		10. Security considerations . . . . . . . . . . . . . . . . . . . 31
	10.1. Security considerations for header compression . . . . . 30		10.1. Security considerations for header compression . . . . . 31
	10.2. Security considerations for fragmentation . . . . . . . 31		10.2. Security considerations for fragmentation . . . . . . . 32
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
	12.1. Normative References . . . . . . . . . . . . . . . . . . 32		12.1. Normative References . . . . . . . . . . . . . . . . . . 33
	12.2. Informative References . . . . . . . . . . . . . . . . . 32		12.2. Informative References . . . . . . . . . . . . . . . . . 33
	Appendix A. Fragmentation examples . . . . . . . . . . . . . . . 32		Appendix A. Fragmentation examples . . . . . . . . . . . . . . . 33
	Appendix B. Rule IDs for fragmentation . . . . . . . . . . . . . 35		Appendix B. Rule IDs for fragmentation . . . . . . . . . . . . . 36
	Appendix C. Note . . . . . . . . . . . . . . . . . . . . . . . . 36		Appendix C. Note . . . . . . . . . . . . . . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
	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. Some LPWAN networks		connectivity to the node within a LPWAN network. Some LPWAN networks
	properties can be exploited for an efficient header compression:		properties can be exploited to get an efficient 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 Devices (Dev) exchanging information with LPWAN		summarized to Devices (Dev) exchanging information with LPWAN
	Application Server (App) through a Network Gateway (NGW).		Application Server (App) through a Network Gateway (NGW).
	o Traffic flows are mostly known in advance, since devices embed		o Traffic flows are mostly known in advance, since devices embed
	built-in applications. Contrary to computers or smartphones, new		built-in applications. Contrary to computers or smartphones, new
	applications cannot be easily installed.		applications cannot be easily installed.
	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
	the header format order. This context is static (the values on the		the header format order. This context is static (the values on the
	header fields do not change over time) avoiding complex		header fields do not change over time) avoiding complex
	resynchronization mechanisms, incompatible with LPWAN		resynchronization mechanisms, incompatible with LPWAN
	characteristics. In most of the cases, IPv6/UDP headers are reduced		characteristics. In most of the cases, IPv6/UDP headers are reduced
	to a small context identifier.		to a small context identifier.
	The SCHC header compression mechanism is independent of the specific		The SCHC header compression mechanism is independent from the
	LPWAN technology over which it will be used.		specific LPWAN technology over which it will be used.
	LPWAN technologies are also characterized, among others, by a very		LPWAN technologies are also characterized, among others, by a very
	reduced data unit and/or payload size [I-D.ietf-lpwan-overview].		reduced data unit and/or payload size [I-D.ietf-lpwan-overview].
	However, some of these technologies do not support layer two		However, some of these technologies do not support layer two
	fragmentation, therefore the only option for these to support the		fragmentation, therefore the only option for them to support the IPv6
	IPv6 MTU requirement of 1280 bytes [RFC2460] is the use of a		MTU requirement of 1280 bytes [RFC2460] is the use of a fragmentation
	fragmentation protocol at the adaptation layer below IPv6. This		protocol at the adaptation layer below IPv6. This draft defines also
	draft defines also a fragmentation functionality to support the IPv6		a fragmentation functionality to support the IPv6 MTU requirements
	MTU requirements over LPWAN technologies. Such functionality has		over LPWAN technologies. Such functionality has been designed under
	been designed under the assumption that data unit reordering will not		the assumption that data unit reordering will not happen between the
	happen between the entity performing fragmentation and the entity		entity performing fragmentation and the entity performing reassembly.
	performing reassembly.
	2. LPWAN Architecture		2. LPWAN Architecture
	LPWAN technologies have similar architectures but different		LPWAN technologies have similar architectures but different
	terminology. We can identify different types of entities in a		terminology. We can identify different types of entities in a
	typical LPWAN network, see Figure 1:		typical LPWAN network, see Figure 1:
	o Devices (Dev) are the end-devices or hosts (e.g. sensors,		o Devices (Dev) are the end-devices or hosts (e.g. sensors,
	actuators, etc.). There can be a high density of devices per radio		actuators, etc.). There can be a high density of devices per radio
	gateway.		gateway.
	o The Radio Gateway (RG), which is the end point of the constrained		o The Radio Gateway (RG), which is the end point of the constrained
	link.		link.
	o The Network Gateway (NGW) is the interconnection node between the		o The Network Gateway (NGW) is the interconnection node between the
	Radio Gateway and the Internet.		Radio Gateway and the Internet.
	o LPWAN-AAA Server, which controls the user authentication, the		o LPWAN-AAA Server, which controls the user authentication and the
	applications. We use the term LPWAN-AAA server because we are not		applications. We use the term LPWAN-AAA server because we are not
	assuming that this entity speaks RADIUS or Diameter as many/most AAA		assuming that this entity speaks RADIUS or Diameter as many/most AAA
	servers do, but equally we don't want to rule that out, as the		servers do, but equally we don't want to rule that out, as the
	functionality will be similar.		functionality will be similar.
	o Application Server (App)		o Application Server (App)
	+------+		+------+
	() () () | |LPWAN-|		() () () | |LPWAN-|
	() () () () / \ +---------+ | AAA |		() () () () / \ +---------+ | AAA |
	() () () () () () / \=======| ^ |====|Server| +-----------+		() () () () () () / \=====| ^ |===|Server| +-----------+
	() () () | | <--|--> | +------+ |APPLICATION|		() () () | | <--|--> | +------+ |APPLICATION|
	() () () () / \============| v |==============| (App) |		() () () () / \==========| v |=============| (App) |
	() () () / \ +---------+ +-----------+		() () () / \ +---------+ +-----------+
	Dev Radio Gateways NGW		Dev Radio Gateways NGW
	Figure 1: LPWAN Architecture		Figure 1: LPWAN Architecture
	3. Terminology		3. Terminology
	This section defines the terminology and acronyms used in this		This section defines the terminology and acronyms used in this
	document.		document.
			o App: LPWAN Application. An application sending/receiving IPv6
			packets to/from the Device.
			o APP-IID: Application Interface Identifier. Second part of the
			IPv6 address to identify the application interface
			o Bi: Bidirectional, it can be used in both senses
	o CDA: Compression/Decompression Action. An action that is perfomed		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 Dev: Device. Node connected to the LPWAN. A Dev may implement		o Dev: Device. Node connected to the LPWAN. A Dev may implement
	SCHC.		SCHC.
	o App: LPWAN Application. An application sending/receiving IPv6		o Dev-IID: Device Interface Identifier. Second part of the IPv6
	packets to/from the Device.		address to identify the device interface
	o SCHC C/D: LPWAN Compressor/Decompressor. A process in the network
	to achieve compression/decompressing headers. SCHC C/D uses SCHC
	rules to perform compression and decompression.
	o MO: Matching Operator. An operator used to match a value
	contained in a header field with a value contained in a Rule.
	o Rule: A set of header field values.
	o Rule ID: An identifier for a rule, SCHC C/D and Dev share the same		o DI: Direction Indicator is a differentiator for matching in order
	Rule ID for a specific flow.		to be able to have different values for both sides.
	o TV: Target value. A value contained in the Rule that will be		o Dw: Down Link direction for compression, from SCHC C/D to Dev
	matched with the value of a header field.
	o FID: Field Indentifier is an index to describe the header fields		o FID: Field Indentifier is an index to describe the header fields
	in the Rule		in the Rule
	o FP: Field Position is a list of possible correct values that a		o FP: Field Position is a list of possible correct values that a
	field may use		field may use
	o DI: Direction Indicator is a differentiator for matching in order
	to be able to have different values for both sides.
	o IID: Interface Identifier. See the IPv6 addressing architecture		o IID: Interface Identifier. See the IPv6 addressing architecture
	[RFC7136]		[RFC7136]
	o Dev-IID: Device Interface Identifier. Second part of the IPv6		o MO: Matching Operator. An operator used to match a value
	address to identify the device interface		contained in a header field with a value contained in a Rule.
	o APP-IID: Application Interface Identifier. Second part of the		o Rule: A set of header field values.
	IPv6 address to identify the application interface
	o Dw: Down Link direction for compression, from SCHC C/D to Dev		o Rule ID: An identifier for a rule, SCHC C/D and Dev share the same
			Rule ID for a specific flow.
	o Up: Up Link direction for compression, from Dev to SCHC C/D		o SCHC C/D: Static Context Header Compression Compressor/
			Decompressor. A process in the network to achieve compression/
			decompressing headers. SCHC C/D uses SCHC rules to perform
			compression and decompression.
	o Bi: Bidirectional, it can be used in both senses		o TV: Target value. A value contained in the Rule that will be
			matched with the value of a header field.
			o Up: Up Link direction for compression, from Dev to SCHC C/D
	4. Static Context Header Compression		4. 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 [RFC5795]. Based on		other header compression mechanisms such as RoHC [RFC5795]. Based on
	the fact that the nature of data flows is highly predictable in LPWAN		the fact that the nature of data flows is highly predictable in LPWAN
	networks, a static context may be stored on the Device (Dev). The		networks, some static contexts may be stored on the Device (Dev).
	context must be stored in both ends, and it can either be learned by		The contexts must be stored in both ends, and it can either be
	a provisioning protocol or by out of band means or it can be pre-		learned by a provisioning protocol or by out of band means or it can
	provosioned, etc. The way the context is learned on both sides is		be pre-provosioned, etc. The way the context is learned on both
	out of the scope of this document.		sides is out of the scope of this document.
	Dev App		Dev App
	+---------------+ +---------------+		+--------------+ +--------------+
	| APP1 APP2 APP3| |APP1 APP2 APP3|		|APP1 APP2 APP3| |APP1 APP2 APP3|
	| | | |		| | | |
	| UDP | | UDP |		| UDP | | UDP |
	| IPv6 | | IPv6 |		| IPv6 | | IPv6 |
	| | | |		| | | |
	| SCHC C/D | | |		| SCHC C/D | | |
	| (context) | | |		| (context) | | |
	+--------+------+ +-------+-------+		+-------+------+ +-------+------+
	| +--+ +----+ +---------+ .		| +--+ +----+ +---------+ .
	+~~ |RG| === |NGW | === |SCHC C/D |... Internet ...		+~~ |RG| === |NGW | === |SCHC C/D |... Internet ..
	+--+ +----+ |(context)|		+--+ +----+ |(context)|
	+---------+		+---------+
	Figure 2: Architecture		Figure 2: Architecture
	Figure 2 based on [I-D.ietf-lpwan-overview] terminology represents		Figure 2 represents the architecture for compression/decompression,
	the architecture for compression/decompression. The Device is		it is based on [I-D.ietf-lpwan-overview] terminology. The Device is
	sending applications flows using IPv6 or IPv6/UDP protocols. These		sending applications flows using IPv6 or IPv6/UDP protocols. These
	flows are compressed by an Static Context Header Compression		flows are compressed by an Static Context Header Compression
	Compressor/Decompressor (SCHC C/D) to reduce headers size. Resulting		Compressor/Decompressor (SCHC C/D) to reduce headers size. Resulting
	information is sent on a layer two (L2) frame to the LPWAN Radio		information is sent on a layer two (L2) frame to a LPWAN Radio
	Network to a Radio Gateway (RG) which forwards the frame to a Network		Network (RG) which forwards the frame to a Network Gateway (NGW).
	Gateway (NGW). The NGW sends the data to a SCHC C/D for		The NGW sends the data to a SCHC C/D for decompression which shares
	decompression which shares the same rules with the Dev. The SCHC C/D		the same rules with the Dev. The SCHC C/D can be located on the
	can be located on the Network Gateway (NGW) or in another place as		Network Gateway (NGW) or in another place as long as a tunnel is
	long as a tunnel is established between the NGW and the SCHC C/D.		established between the NGW and the SCHC C/D. The SCHC C/D in both
	SCHC C/D in both sides must share the same set of Rules. After		sides must share the same set of Rules. After decompression, the
	decompression, the packet can be sent on the Internet to one or		packet can be sent on the Internet to one or several LPWAN
	several LPWAN Application Servers (App).		Application Servers (App).
	The SCHC C/D process is bidirectional, so the same principles can be		The SCHC C/D process is bidirectional, so the same principles can be
	applied in the other direction.		applied in the other direction.
	4.1. SCHC Rules		4.1. SCHC Rules
	The main idea of the SCHC compression scheme is to send the Rule id		The main idea of the SCHC compression scheme is to send the Rule id
	to the other end that match as much as possible the original packet		to the other end instead of sending known field values. This Rule id
	values instead of sending known field values. When a value is known		identifies a rule that match as much as possible the original packet
	by both ends, it is not necessary sent through the LPWAN network.		values. When a value is known by both ends, it is not necessary sent
			through the LPWAN network.
	The context contains a list of rules (cf. Figure 3). Each Rule		The context contains a list of rules (cf. Figure 3). 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 field position (FP), a direction indicator (DI),		identifier (FID), a field position (FP), a direction indicator (DI),
	a target value (TV), a matching operator (MO) and a Compression/		a target value (TV), a matching operator (MO) and a Compression/
	Decompression Action (CDA).		Decompression Action (CDA).
	/--------------------------------------------------------------\		/--------------------------------------------------------------\
	| Rule N |		| Rule N |
	/--------------------------------------------------------------\|		/--------------------------------------------------------------\|
	skipping to change at page 8, line 31 ¶		skipping to change at page 8, line 31 ¶
	\--------------------------------------------------------------/		\--------------------------------------------------------------/
	Figure 3: Compression/Decompression Context		Figure 3: 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, the description of the header field must be performed in the		rule, the description of the header field must be performed in the
	format packet order.		format packet order.
	The Rule describes also the compressed header fields which are		The Rule also describes the compressed header fields which are
	transmitted regarding their position in the rule which is used for		transmitted regarding their position in the rule which is used for
	data serialization on the compressor side and data deserialization on		data serialization on the compressor side and data deserialization on
	the decompressor side.		the decompressor side.
	The Context describes the header fields and its values with the		The Context describes the header fields and its values with the
	following entries:		following entries:
	o A Field ID (FID) is a unique value to define the header field.		o A Field ID (FID) is a unique value to define the header field.
	o A Field Position (FP) indicating if several instances of the field		o A Field Position (FP) indicating if several instances of the field
	skipping to change at page 9, line 49 ¶		skipping to change at page 9, line 49 ¶
	4.3. Packet processing		4.3. 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 packet's headers. When doing		will be used to compress the packet's headers. When doing
	compression from Dw to Up the SCHC C/D needs to find the correct		compression from Dw to Up the SCHC C/D needs to find the correct
	Rule to use by identifying its Dev-ID and the Rule-ID. In the Up		Rule to use by identifying its Dev-ID and the Rule-ID. In the Up
	situation only the Rule-ID is used. The next step is to choose		situation only the Rule-ID is used. The next step is to choose
	the fields by their direction, using the direction indicator (DI),		the fields by their direction, using the direction indicator (DI),
	so the fields that does not correspond to the appropiated DI will		so the fields that do not correspond to the appropiated DI will be
	be excluded. Next, then fields are identified according to their		excluded. Next, then the fields are identified according to their
	field identifier (FID) and field position (FP). If the field		field identifier (FID) and field position (FP). If the field
	position does not correspond then the Rule is not use and the SCHC		position does not correspond then the Rule is not use and the SCHC
	take next Rule. Once the DI and the FP correspond to the header		take next Rule. Once the DI and the FP correspond to the header
	information, each field's value is then compared to the		information, each field's value is then compared to the
	corresponding target value (TV) stored in the Rule for that		corresponding target value (TV) stored in the Rule for that
	specific field using the matching operator (MO). If all the		specific field using the matching operator (MO). If all the
	fields in the packet's header satisfy all the matching operators		fields in the packet's header satisfy all the matching operators
	(MOs) of a Rule (i.e. all results are True), the fields of the		(MOs) of a Rule (i.e. all results are True), the fields of the
	header are then processed according to the Compression/		header are then processed according to the Compression/
	Decompession Actions (CDAs) and a compressed header is obtained.		Decompession Actions (CDAs) and a compressed header is obtained.
	Otherwise the next rule is tested. If no eligible rule is found,		Otherwise the next rule is tested. If no eligible rule is found,
	then the header must be sent without compression, in which case		then the header must be sent without compression, in which case
	the fragmentation process must be required.		the fragmentation process must be required.
	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,
	information is sent in the order expressed in the Rule for the		directly followed by the payload. The product of field
			compression is sent in the order expressed in the Rule for the
	matching fields. The way the Rule ID is sent depends on the		matching fields. The way the Rule ID is sent depends on the
	specific LPWAN layer two technology and will be specified in a		specific LPWAN layer two technology and will be specified in a
	specific document, and is out of the scope of this document. For		specific document, and is out of the scope of this document. For
	example, it can be either included in a Layer 2 header or sent in		example, it can be either included in a Layer 2 header or sent in
	the first byte of the L2 payload. (cf. Figure 4).		the first byte of the L2 payload. (cf. Figure 4).
	o decompression: In both directions, The receiver identifies the		o decompression: In both directions, The receiver identifies the
	sender through its device-id (e.g. MAC address) and selects the		sender through its device-id (e.g. MAC address) and selects the
	appropriate Rule through the Rule ID. This Rule gives the		appropriate Rule through the Rule ID. This Rule gives the
	compressed header format and associates these values to header		compressed header format and associates these values to the header
	fields. It applies the CDA action to reconstruct the original		fields. It applies the CDA action to reconstruct the original
	header fields. The CDA application order can be different of the		header fields. The CDA application order can be different of the
	order given by the Rule. For instance Compute-* may be applied at		order given by the Rule. For instance Compute-* may be applied at
	end, after the other CDAs.		end, after the other CDAs.
	+--- ... ---+-------------- ... --------------+		If after using SCHC compression and adding the payload to the L2
	| Rule ID |Compressed Hdr Fields information|		frame the datagram is not multiple of 8 bits, padding may be used.
	+--- ... ---+-------------- ... --------------+
			+--- ... ---+-------------- ... --------------+-------------+--...--+
			| Rule ID |Compressed Hdr Fields information| payload |padding|
			+--- ... ---+-------------- ... --------------+-------------+--...--+
	Figure 4: LPWAN Compressed Format Packet		Figure 4: LPWAN Compressed Format Packet
	5. Matching operators		5. Matching operators
	Matching Operators (MOs) are functions used by both SCHC C/D		Matching Operators (MOs) are functions used by both SCHC C/D
	endpoints involved in the header compression/decompression. They are		endpoints involved in the header compression/decompression. They are
	not typed and can be applied indifferently to integer, string or any		not typed and can be applied indifferently to integer, string or any
	other data type. The result of the operation can either be True or		other data type. The result of the operation can either be True or
	False. MOs are defined as follows:		False. MOs are defined as follows:
	skipping to change at page 11, line 21 ¶		skipping to change at page 11, line 24 ¶
	indicating the number of bits, to proceed to the matching.		indicating the number of bits, to proceed to the matching.
	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 values. Each value is idenfied by a short ID (or index).		list of values. Each value is idenfied by a short ID (or index).
	This operator matches if a field value is equal to one of those		This operator matches if a field value is equal to one of those
	target values.		target values.
	6. Compression Decompression Actions (CDA)		6. Compression Decompression Actions (CDA)
	The Compression Decompression Actions (CDA) describes the action		The Compression Decompression Action (CDA) describes the actions
	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.
	/--------------------+-------------+----------------------------\		/--------------------+-------------+----------------------------\
	| Action | 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 |
	|mapping-sent |send index |value from index on a table |		|mapping-sent |send index |value from index on a table |
	skipping to change at page 12, line 13 ¶		skipping to change at page 12, line 15 ¶
	rule or may be sent with the compressed header.		rule or may be sent with the compressed header.
	If the field is identified as variable, then its size must be sent		If the field is identified as variable, then its size must be sent
	first using the following coding:		first using the following coding:
	o If the size is between 0 and 14 bytes it is sent using 4 bits.		o If the size is between 0 and 14 bytes it is sent using 4 bits.
	o For values between 15 and 255, the first 4 bit sent are set to 1		o For values between 15 and 255, the first 4 bit sent are set to 1
	and the size is sent using 8 bits.		and the size is sent using 8 bits.
	o For higher value, the first 12 bytes are set to 1 and the size is		o For higher value, the first 12 bits are set to 1 and the size is
	sent on 2 bytes.		sent on 2 bytes.
	6.1. not-sent CDA		6.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 action is generally used with the "equal" MO. If		Decompressor. This action is generally used with the "equal" MO. 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.
	skipping to change at page 12, line 40 ¶		skipping to change at page 12, line 42 ¶
	6.2. value-sent CDA		6.2. value-sent CDA
	The value-sent action 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 implicitly (the size is known by		know the size of the field, either implicitly (the size is known by
	both sides) or explicitly 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
	compressed header message. The decompressor restores the field value
	with the one received from the LPWAN
	6.3. mapping-sent		6.3. mapping-sent
	mapping-sent is used to send a smaller index associated to the list		mapping-sent is used to send a smaller index associated to the list
	of values in the Target Value. This function is used together with		of values in the Target Value. This function is used together with
	the "match-mapping" MO.		the "match-mapping" MO.
	The compressor looks in the TV to find the field value and send the		The compressor looks in the TV to find the field value and send the
	corresponding index. The decompressor uses this index to restore the		corresponding index. The decompressor uses this index to restore the
	field value.		field value.
	The number of bits sent is the minimal size to code all the possible		The number of bits sent is the minimal size to code all the possible
	indexes.		indexes.
	6.4. LSB CDA		6.4. LSB CDA
	LSB action is used to avoid sendind the known part of the packet		LSB action is used to avoid sending the known part of the packet
	field header to the other end. This action is used together with the		field header to the other end. This action is used together with the
	"MSB" MO. A length can be specified in the rule to indicate how many		"MSB" MO. A length can be specified in the rule to indicate how many
	bits have to be sent. If not length is specified, the number of bits		bits have to be sent. If not length is specified, the number of bits
	sent are the field length minus the bits length specified in the MSB		sent are the field length minus the bits length specified in the MSB
	MO.		MO.
	The compressor sends the "length" Least Significant Bits. The		The compressor sends the "length" Least Significant Bits. The
	decompressor combines the value received with the Target Value.		decompressor combines the value received with the Target Value.
	If this action is made on a variable length field, the remaning size		If this action is made on a variable length field, the remaning size
	in byte has to be sent before.		in byte has to be sent before.
	6.5. DEViid, APPiid CDA		6.5. DEViid, APPiid CDA
	These functions are used to process respectively the Dev and the App		These functions are used to process respectively the Dev and the App
	Interface Identifiers (Deviid and Appiid) of the IPv6 addresses.		Interface Identifiers (Deviid and Appiid) of the IPv6 addresses.
	Appiid CDA is less common, since current LPWAN technologies frames		Appiid CDA is less common, since current LPWAN technologies frames
	contain a single address.		contain a single address.
	The IID value can be computed from the Device ID present in the Layer		The IID value may be computed from the Device ID present in the Layer
	2 header. The computation is specific for each LPWAN technology and		2 header. The computation is specific for each LPWAN technology and
	depends on the Device ID size.		may depend on the Device ID size.
	In the downstream direction, these CDA are used to determine the L2		In the downstream direction, these CDA may be used to determine the
	addresses used by the LPWAN.		L2 addresses used by the LPWAN.
	6.6. Compute-*		6.6. Compute-*
	Thes classes of functions are used by the decompressor to compute the		These classes of functions are used by the decompressor to compute
	compressed field value based on received information. Compressed		the compressed field value based on received information. Compressed
	fields are elided during compression and reconstructed during		fields are elided during compression and reconstructed during
	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 CDA 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 SCHC C/D. This field may be used to compute UDP		received by the SCHC C/D. This field may be used to compute UDP
	checksum.		checksum.
	skipping to change at page 16, line 41 ¶		skipping to change at page 16, line 41 ¶
	7.7.2. IPv6 source and destination IID		7.7.2. IPv6 source and destination IID
	If the DEV or APP 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 CDA		that case, the TV is not set, the MO is set to "ignore" and the CDA
	is set to "DEViid" or "APPiid". Note that the LPWAN technology is		is set to "DEViid" or "APPiid". Note that the LPWAN technology is
	generally carrying a single device identifier corresponding to the		generally carrying a single device identifier corresponding to the
	DEV. The SCHC C/D may also not be aware of these values.		DEV. The SCHC C/D may also not be aware of these values.
	If the DEV address has a static value that is not derivated from the		If the DEV address has a static value that is not derivated from an
	EUI-64, then TV contains the value, the MO operator is set to "equal"		IEEE EUI-64, then TV contains the actual Dev address value, the MO
	and the CDA is set to "not-sent".		operator is set to "equal" and the CDA is set to "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 IIDs, the MO is set to "match-mapping" and the CDA is set to		possible IIDs, 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 CDA is set to LSB.		set to MSB and the CDA 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
	skipping to change at page 21, line 18 ¶		skipping to change at page 21, line 18 ¶
	The second and third rules use global addresses. The way the Dev		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.
	9. Fragmentation		9. Fragmentation
	9.1. Overview		9.1. Overview
	Fragmentation support in LPWAN is mandatory when the underlying LPWAN		Fragmentation supported in LPWAN is mandatory when the underlying
	technology is not capable of fulfilling the IPv6 MTU requirement.		LPWAN technology is not capable of fulfilling the IPv6 MTU
	Fragmentation is used if, after SCHC header compression, the size of		requirement. Fragmentation is used if, after SCHC header
	the resulting IPv6 packet is larger than the L2 data unit maximum		compression, the size of the resulting IPv6 packet is larger than the
	payload. Fragmentation is also used if SCHC header compression has		L2 data unit maximum payload. Fragmentation is also used if SCHC
	not been able to compress an IPv6 packet that is larger than the L2		header compression has not been able to compress an IPv6 packet that
	data unit maximum payload. In LPWAN technologies, the L2 data unit		is larger than the L2 data unit maximum payload. In LPWAN
	size typically varies from tens to hundreds of bytes. If the entire		technologies, the L2 data unit size typically varies from tens to
	IPv6 datagram fits within a single L2 data unit, the fragmentation		hundreds of bytes. If the entire IPv6 datagram fits within a single
	mechanism is not used and the packet is sent unfragmented.		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 IPv6 datagram. On the other hand, in order		retransmitting the full IPv6 datagram. On the other hand, in order
	to preserve energy, Devices are sleeping most of the time and may		to preserve energy, Devices are sleeping most of the time and may
	receive data during a short period of time after transmission. In		receive data during a short period of time after transmission. In
	order to adapt to the capabilities of various LPWAN technologies,		order to adapt to the capabilities of various LPWAN technologies,
	skipping to change at page 22, line 33 ¶		skipping to change at page 22, line 33 ¶
	on top of an L2 LPWAN technology with symmetric characteristics for		on top of an L2 LPWAN technology with symmetric characteristics for
	uplink and downlink).		uplink and downlink).
	In the No ACK option, the receiver MUST NOT issue acknowledgments		In the No ACK option, the receiver MUST NOT issue acknowledgments
	(ACK).		(ACK).
	In Window mode - ACK "always", an ACK is transmitted by the fragment		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/or missing fragments from the window of fragments.		and/or missing fragments from the window of fragments. Upon receipt
			of an ACK that informs about any lost fragments, the sender
			retransmits the lost fragments, as long as a maximum of
			MAX_FRAG_RETRIES is not exceeded for each one of those fragments.
			The default value of MAX_FRAG_RETRIES is not stated in this document,
			and it is expected to be defined in other documents (e.g. technology-
			specific profiles).
	In Window mode - ACK on error, an ACK is transmitted by the fragment		In Window mode - ACK on error, an ACK is transmitted by the fragment
	receiver after a window of fragments have been sent, only if at least		receiver after a window of fragments have been sent, only if at least
	one of the fragments in the window has been lost. In this mode, the		one of the fragments in the window has been lost. In this mode, the
	ACK informs the sender about received and/or missing fragments from		ACK informs the sender about received and/or missing fragments from
	the window of fragments.		the window of fragments. Upon receipt of an ACK that informs about
			any lost fragments, the sender retransmits the lost fragments. The
	In Window mode, upon receipt of an ACK that informs about any lost		maximum number of ACKs to be sent by the receiver for a specific
	fragments, the sender retransmits the lost fragments. The maximum		window, denoted MAX_ACKS_PER_WINDOW, is not stated in this document,
	number of ACKs to be sent by the receiver for a specific window,		and it is expected to be defined in other documents (e.g. technology-
	denoted MAX_ACKS_PER_WINDOW, is not stated in this document, and it
	is expected to be defined in other documents (e.g. technology-
	specific profiles).		specific profiles).
	This document does not make any decision as to which fragment		This document does not make any decision as to which fragment
	delivery reliability option(s) need to be supported over a specific		delivery reliability option(s) need to be supported over a specific
	LPWAN technology.		LPWAN technology.
	Examples of the different reliability options described are provided		Examples of the different reliability options described are provided
	in Appendix A.		in Appendix A.
	9.3. Reliability options: discussion		9.3. Reliability options: discussion
	skipping to change at page 25, line 28 ¶		skipping to change at page 25, line 34 ¶
	<------------ R ---------->		<------------ R ---------->
	<--T--> 1 <--N-->		<--T--> 1 <--N-->
	+-- ... --+- ... -+-+- ... -+		+-- ... --+- ... -+-+- ... -+
	| Rule ID | DTag |W| CFN |		| Rule ID | DTag |W| CFN |
	+-- ... --+- ... -+-+- ... -+		+-- ... --+- ... -+-+- ... -+
	Figure 10: Fragmentation Header for Fragments except the Last One,		Figure 10: Fragmentation Header for Fragments except the Last One,
	Window mode		Window mode
	The last fragment of an IPv6 datagram SHALL contain a fragmentation		In the No ACK option, the last fragment of an IPv6 datagram SHALL
	header that conforms to the format shown in Figure 11. The total		contain a fragmentation header that conforms to the format shown in
	size of this fragmentation header is R+M bits.		Figure 11. The total size of this fragmentation header is R+M bits.
	<------------- R ------------>		<------------- R ------------>
	<- T -> <- N -> <---- M ----->		<- T -> <- N -> <---- M ----->
	+---- ... ---+- ... -+- ... -+---- ... ----+		+---- ... ---+- ... -+- ... -+---- ... ----+
	| Rule ID | DTag | 11..1 | MIC |		| Rule ID | DTag | 11..1 | MIC |
	+---- ... ---+- ... -+- ... -+---- ... ----+		+---- ... ---+- ... -+- ... -+---- ... ----+
	Figure 11: Fragmentation Header for the Last Fragment		Figure 11: Fragmentation Header for the Last Fragment, No ACK option
	o Rule ID: This field has a size of R - T - N - 1 bits in all		In any of the Window modes, the last fragment of an IPv6 datagram
	fragments that are not the last one, when Window mode is used. In		SHALL contain a fragmentation header that conforms to the format
	all other fragments, the Rule ID field has a size of R - T - N		shown in Figure 12. The total size of this fragmentation header is
	bits.		R+M bits.
			<------------ R ------------>
			<- T -> 1 <- N -> <---- M ----->
			+-- ... --+- ... -+-+- ... -+---- ... ----+
			| Rule ID | DTag |W| 11..1 | MIC |
			+-- ... --+- ... -+-+- ... -+---- ... ----+
			Figure 12: Fragmentation Header for the Last Fragment, Window mode
			o Rule ID: This field has a size of R - T - N - 1 bits when Window
			mode is used. In No ACK mode, the Rule ID field has a size of R -
			T - N bits.
	o DTag: The size of the DTag field is T bits, which may be set to a		o DTag: 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		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		fragments that carry the same IPv6 datagram MUST be set to the
	same value. DTag MUST be set sequentially increasing from 0 to		same value. DTag MUST be set sequentially increasing from 0 to
	2^T - 1, and MUST wrap back from 2^T - 1 to 0.		2^T - 1, and MUST wrap back from 2^T - 1 to 0.
	o CFN: This field is an unsigned integer, with a size of N bits,		o CFN: This field is an unsigned integer, with a size of N bits,
	that carries the CFN of the fragment. In the No ACK option, N=1.		that carries the CFN of the fragment. In the No ACK option, N=1.
	For the rest of options, N equal to or greater than 3 is		For the rest of options, N equal to or greater than 3 is
	skipping to change at page 26, line 40 ¶		skipping to change at page 27, line 11 ¶
	o MIC: This field, which has a size of M bits, carries the MIC for		o MIC: This field, which has a size of M bits, carries the MIC for
	the IPv6 packet.		the IPv6 packet.
	The values for R, N, T and M are not specified in this document, and		The values for R, N, T and M are not specified in this document, and
	have to be determined in other documents (e.g. technology-specific		have to be determined in other documents (e.g. technology-specific
	profile documents).		profile documents).
	9.5.3. ACK format		9.5.3. ACK format
	The format of an ACK is shown in Figure 12:		The format of an ACK is shown in Figure 13:
	<-------- R ------->		<-------- R ------->
	<- T -> 1		<- T -> 1
	+---- ... --+-... -+-+----- ... ---+		+---- ... --+-... -+-+----- ... ---+
	| Rule ID | DTag |W| bitmap |		| Rule ID | DTag |W| bitmap |
	+---- ... --+-... -+-+----- ... ---+		+---- ... --+-... -+-+----- ... ---+
	Figure 12: Format of an ACK		Figure 13: Format of an ACK
	Rule ID: In all ACKs, Rule ID has a size of R - T - 1 bits.		Rule ID: In all ACKs, Rule ID has a size of R - T - 1 bits.
	DTag: DTag has a size of T bits. DTag carries the same value as the		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		DTag field in the fragments carrying the IPv6 datagram for which this
	ACK is intended.		ACK is intended.
	W: This field has a size of 1 bit. In all ACKs, the W bit carries		W: This field has a size of 1 bit. In all ACKs, the W bit carries
	the same value as the W bit carried by the fragments whose reception		the same value as the W bit carried by the fragments whose reception
	is being positively or negatively acknowledged by the ACK.		is being positively or negatively acknowledged by the ACK.
	skipping to change at page 27, line 26 ¶		skipping to change at page 27, line 44 ¶
	0 or Ceiling(Number_of_Fragments/8) octets, where Number_of_Fragments		0 or Ceiling(Number_of_Fragments/8) octets, where Number_of_Fragments
	denotes the number of fragments of a window. The bitmap is a		denotes the number of fragments of a window. The bitmap is a
	sequence of bits, where the n-th bit signals whether the n-th		sequence of bits, where the n-th bit signals whether the n-th
	fragment transmitted in the current window has been correctly		fragment transmitted in the current window has been correctly
	received (n-th bit set to 1) or not (n-th bit set to 0). Remaining		received (n-th bit set to 1) or not (n-th bit set to 0). Remaining
	bits with bit order greater than the number of fragments sent (as		bits with bit order greater than the number of fragments sent (as
	determined by the receiver) are set to 0, except for the last bit in		determined by the receiver) are set to 0, except for the last bit in
	the bitmap, which is set to 1 if the last fragment of the window has		the bitmap, which is set to 1 if the last fragment of the window has
	been correctly received, and 0 otherwise. Feedback on reception of		been correctly received, and 0 otherwise. Feedback on reception of
	the fragment with CFN = 2^N - 1 (last fragment carrying an IPv6		the fragment with CFN = 2^N - 1 (last fragment carrying an IPv6
	packet) is only given by the last bit of the corresponding window.		packet) is only given by the last bit of the corresponding bitmap.
	Absence of the bitmap in an ACK confirms correct reception of all		Absence of the bitmap in an ACK confirms correct reception of all
	fragments to be acknowledged by means of the ACK.		fragments to be acknowledged by means of the ACK.
	Figure 13 shows an example of an ACK (N=3), where the bitmap		Figure 14 shows an example of an ACK (N=3), where the bitmap
	indicates that the second and the fifth fragments have not been		indicates that the second and the fifth fragments have not been
	correctly received.		correctly received.
	<------- R ------->		<------- R ------->
	<- T -> 0 1 2 3 4 5 6 7		<- T -> 0 1 2 3 4 5 6 7
	+---- ... --+-... -+-+-+-+-+-+-+-+-+-+		+---- ... --+-... -+-+-+-+-+-+-+-+-+-+
	| Rule ID | DTag |W|1|0|1|1|0|1|1|1|		| Rule ID | DTag |W|1|0|1|1|0|1|1|1|
	+---- ... --+-... -+-+-+-+-+-+-+-+-+-+		+---- ... --+-... -+-+-+-+-+-+-+-+-+-+
	Figure 13: Example of the bitmap in an ACK (in Window mode, for N=3)		Figure 14: Example of the bitmap in an ACK (in Window mode, for N=3)
	Figure 14 illustrates an ACK without a bitmap.		Figure 15 illustrates an ACK without a bitmap.
	<------- R ------->		<------- R ------->
	<- T ->		<- T ->
	+---- ... --+-... -+-+		+---- ... --+-... -+-+
	| Rule ID | DTag |W|		| Rule ID | DTag |W|
	+---- ... --+-... -+-+		+---- ... --+-... -+-+
	Figure 14: Example of an ACK without a bitmap		Figure 15: Example of an ACK without a bitmap
	Note that, in order to exploit the available L2 payload space to the		Note that, in order to exploit the available L2 payload space to the
	fullest, a bitmap may have a size smaller than 2^N bits. In that		fullest, a bitmap may have a size smaller than 2^N bits. In that
	case, the window in use will have a size lower than 2^N-1 fragments.		case, the window in use will have a size lower than 2^N-1 fragments.
	For example, if the maximum available space for a bitmap is 56 bits,		For example, if the maximum available space for a bitmap is 56 bits,
	N can be set to 6, and the window size can be set to a maximum of 56		N can be set to 6, and the window size can be set to a maximum of 56
	fragments.		fragments.
	9.6. Baseline mechanism		9.6. 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),
	(3) Rule ID and (4) DTag to identify all the fragments that belong to		(3) Rule ID and (4) DTag (the latter, if present) to identify all the
	a given IPv6 datagram. The fragment receiver may determine the		fragments that belong to a given IPv6 datagram. The fragment
	fragment delivery reliability option in use for the fragment based on		receiver may determine the fragment delivery reliability option in
	the Rule ID field in that fragment.		use for the fragment based on 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. In		of arrival of the fragments, and the fragment payload sizes. In
	Window mode, the fragment receiver also uses the W bit in the		Window mode, the fragment receiver also uses the W bit in the
	received fragments. Note that the size of the original, unfragmented		received fragments. Note that the size of the original, unfragmented
	IPv6 packet cannot be determined from fragmentation headers.		IPv6 packet cannot be determined from fragmentation headers.
	When Window mode - ACK on error is used, the fragment receiver starts		When Window mode - ACK on error is used, the fragment receiver starts
	a timer (denoted "ACK on Error Timer") upon reception of the first		a timer (denoted "ACK on Error Timer") upon reception of the first
	fragment for an IPv6 datagram. The initial value for this timer is		fragment for an IPv6 datagram. The initial value for this timer is
	not provided by this specification, and is expected to be defined in		not provided by this specification, and is expected to be defined in
	additional documents. This timer is reset every time that a new		additional documents. This timer is reset and restarted every time
	fragment carrying data from the same IPv6 datagram is received. In		that a new fragment carrying data from the same IPv6 datagram is
	Window mode - ACK on error, upon timer expiration, if neither the		received. In Window mode - ACK on error, after reception of the last
	last fragment of the IPv6 datagram nor the last fragment of the		fragment of a window (i.e. the fragment with CFN=0 or CFN=2^N-1), if
	current window (i.e. with CFN=0) have been received, an ACK MUST be		fragment losses have been detected by the fragment receiver in the
	transmitted by the fragment receiver to indicate received and not		current window, the fragment receiver MUST transmit an ACK reporting
	received fragments for the current window.		its available information with regard to sucessfully received and
			missing fragments from the current window. Upon expiration of the
			"ACK on Error Timer", if the receiver knows that at least one
			fragment of the current window has been lost, an ACK MUST be
			transmitted by the fragment receiver to report received and not
			received fragments for the current window. The "ACK on Error Timer"
			is then reset and restarted. In Window mode - ACK on error, the
			fragment sender retransmits any lost fragments reported in an ACK.
			The maximum number of ACKs to be sent by the receiver for a specific
			window, denoted MAX_ACKS_PER_WINDOW, is not stated in this document,
			and it is expected to be defined in other documents (e.g. technology-
			specific profiles).
	Note that, in Window mode, the first fragment of the window is the		Note that, in Window mode, the first fragment of the window is the
	one sent with CFN=2^N-2. Also note that, in Window mode, the		one with CFN=2^N-2. Also note that, in Window mode, the fragment
	fragment with CFN=0 is considered the last fragment of its window,		with CFN=0 is considered the last fragment of its window, except for
	except for the last fragment of the whole packet (with all CFN bits		the last fragment of the whole packet (with all CFN bits set to 1,
	set to 1), which is also the last fragment of the last window. Upon		i.e. CFN=2^N-1), which is also the last fragment of the last window.
	receipt of the last fragment of a window, if Window mode - ACK
	"Always" is used, the fragment receiver MUST send an ACK to the
	fragment sender. The ACK provides feedback on the fragments received
	and lost that correspond to the last window.
	If the recipient receives the last fragment of an IPv6 datagram, it		If Window mode - ACK "always" is used, upon receipt of the last
	checks for the integrity of the reassembled IPv6 datagram, based on		fragment of a window (i.e. the fragment with CFN=0 or CFN=2^N-1), the
	the MIC received. In No ACK mode, if the integrity check indicates		fragment receiver MUST send an ACK to the fragment sender. The ACK
	that the reassembled IPv6 datagram does not match the original IPv6		provides feedback on the fragments received and those not received
	datagram (prior to fragmentation), the reassembled IPv6 datagram MUST		that correspond to the last window. Once all fragments of a window
	be discarded. If Window mode - ACK "Always" is used, the recipient		have been received by the fragment receiver (including retransmitted
	MUST transmit an ACK to the fragment sender. The ACK provides		fragments, if any), the latter sends an ACK without a bitmap to the
	feedback on the fragments that correspond to the last window. If		sender, in order to report sucessful reception of all fragments of
	Window mode - ACK on error is used, the recipient MUST NOT transmit		the window to the fragment sender.
	an ACK to the sender if no losses have been detected for the last
	window. If losses have been detected, the recipient MUST then
	transmit an ACK to the sender to provide feedback on the last window.
	When Window mode - ACK "Always" is used, the fragment sender starts a		When Window mode - ACK "always" is used, the fragment sender starts a
	timer (denoted "ACK Always Timer") after transmitting the last		timer (denoted "ACK Always Timer") after the first transmission
	fragment of a fragmented IPv6 datagram. The fragment sender also		attempt of the last fragment of a window (i.e. the fragment with
	starts the ACK Always Timer after transmitting the last fragment of a		CFN=0 or CFN=2^N-1). In the same reliability option, if one or more
	window. The initial value for this timer is not provided by this		fragments are reported by an ACK to be lost, the sender retransmits
	specification, and is expected to be defined in additional documents.		those fragments and starts the "ACK Always Timer" after the last
	Upon expiration of the timer, if no ACK has been received for the		retransmitted fragment (i.e. the fragment with the lowest CFN) among
	current window, the sender retransmits the last fragment, and it		the set of lost fragments reported by the ACK. The initial value for
	reinitializes and restarts the timer. Note that retransmitting the		the "ACK Always Timer" is not provided by this specification, and it
	last fragment of a window as described serves as an ACK request. The		is expected to be defined in additional documents. Upon expiration
	maximum number of requests for a specific ACK, denoted		of the timer, if no ACK has been received since the timer start, the
	MAX_ACK_REQUESTS, is not stated in this document, and it is expected		sender retransmits the last fragment sent, and it reinitializes and
	to be defined in other documents (e.g. technology-specific profiles).		restarts the timer. Note that retransmitting the last fragment sent
			as described serves as an ACK request. The maximum number of
			requests for a specific ACK, denoted MAX_ACK_REQUESTS, is not stated
			in this document, and it is expected to be defined in other documents
			(e.g. technology-specific profiles). In Window mode - ACK "Always",
			the fragment sender retransmits any lost fragments reported in an
			ACK, as long as the number of retries for each one of those fragments
			does not exceed MAX_FRAG_RETRIES. The default value for
			MAX_FRAG_RETRIES is not provided in this document and it is expected
			to be defined in additional documents. When the fragment sender
			receives an ACK that confirms correct reception of all fragments of a
			window, if there are further fragments to be sent for the same IPv6
			datagram, the fragment sender proceeds to transmitting subsequent
			fragments of the next window.
	In all Window mode options, the fragment sender retransmits any lost		If the recipient receives the last fragment of an IPv6 datagram (i.e.
	fragments reported in an ACK.		the fragment with CFN=2^N-1), it checks for the integrity of the
			reassembled IPv6 datagram, based on the MIC received. In No ACK
			mode, if the integrity check indicates that the reassembled IPv6
			datagram does not match the original IPv6 datagram (prior to
			fragmentation), the reassembled IPv6 datagram MUST be discarded. If
			Window mode - ACK "Always" is used, the recipient MUST transmit an
			ACK to the fragment sender. The ACK provides feedback on the
			fragments from the last window that have been received or not per the
			information available at the receiver. If Window mode - ACK on error
			is used, the recipient MUST NOT transmit an ACK to the sender if no
			losses have been detected for the last window. If losses have been
			detected, the recipient MUST then transmit an ACK to the sender to
			provide feedback on the transmission of the last window of fragments.
	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 value for this timer is not provided by this		flushed. The value for this timer is not provided by this
	skipping to change at page 32, line 38 ¶		skipping to change at page 33, line 38 ¶
	[I-D.ietf-lpwan-overview]		[I-D.ietf-lpwan-overview]
	Farrell, S., "LPWAN Overview", draft-ietf-lpwan-		Farrell, S., "LPWAN Overview", draft-ietf-lpwan-
	overview-04 (work in progress), June 2017.		overview-04 (work in progress), June 2017.
	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 15 illustrates the transmission of an IPv6 packet that needs		Figure 16 illustrates the transmission of an IPv6 packet that needs
	11 fragments in the No ACK option.		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 15: Transmission of an IPv6 packet carried by 11 fragments in		Figure 16: Transmission of an IPv6 packet carried by 11 fragments in
	the No ACK option		the No ACK option
	Figure 16 illustrates the transmission of an IPv6 packet that needs		Figure 17 illustrates the transmission of an IPv6 packet that needs
	11 fragments in Window mode - ACK on error, for N=3, without losses.		11 fragments in Window mode - ACK on error, for N=3, without losses.
	Sender Receiver		Sender Receiver
	|-----W=1, CFN=6----->|		|-----W=1, CFN=6----->|
	|-----W=1, CFN=5----->|		|-----W=1, CFN=5----->|
	|-----W=1, CFN=4----->|		|-----W=1, CFN=4----->|
	|-----W=1, CFN=3----->|		|-----W=1, CFN=3----->|
	|-----W=1, CFN=2----->|		|-----W=1, CFN=2----->|
	|-----W=1, CFN=1----->|		|-----W=1, CFN=1----->|
	|-----W=1, CFN=0----->|		|-----W=1, CFN=0----->|
	(no ACK)		(no ACK)
	|-----W=0, CFN=6----->|		|-----W=0, CFN=6----->|
	|-----W=0, CFN=5----->|		|-----W=0, CFN=5----->|
	|-----W=0, CFN=4----->|		|-----W=0, CFN=4----->|
	|-----W=0, CFN=7----->|MIC checked =>		|-----W=0, CFN=7----->|MIC checked =>
	(no ACK)		(no ACK)
	Figure 16: Transmission of an IPv6 packet carried by 11 fragments in		Figure 17: Transmission of an IPv6 packet carried by 11 fragments in
	Window mode - ACK on error, for N=3, without losses.		Window mode - ACK on error, for N=3, without losses.
	Figure 17 illustrates the transmission of an IPv6 packet that needs		Figure 18 illustrates the transmission of an IPv6 packet that needs
	11 fragments in Window mode - ACK on error, for N=3, with three		11 fragments in Window mode - ACK on error, for N=3, with three
	losses.		losses.
	Sender Receiver		Sender Receiver
	|-----W=1, CFN=6----->|		|-----W=1, CFN=6----->|
	|-----W=1, CFN=5----->|		|-----W=1, CFN=5----->|
	|-----W=1, CFN=4--X-->|		|-----W=1, CFN=4--X-->|
	|-----W=1, CFN=3----->|		|-----W=1, CFN=3----->|
	|-----W=1, CFN=2--X-->|		|-----W=1, CFN=2--X-->|
	|-----W=1, CFN=1----->|		|-----W=1, CFN=1----->|
	skipping to change at page 34, line 25 ¶		skipping to change at page 35, line 25 ¶
	|-----W=1, CFN=2----->|		|-----W=1, CFN=2----->|
	(no ACK)		(no ACK)
	|-----W=0, CFN=6----->|		|-----W=0, CFN=6----->|
	|-----W=0, CFN=5----->|		|-----W=0, CFN=5----->|
	|-----W=0, CFN=4--X-->|		|-----W=0, CFN=4--X-->|
	|-----W=0, CFN=7----->|MIC checked		|-----W=0, CFN=7----->|MIC checked
	|<-----ACK, W=0-------|Bitmap:11000001		|<-----ACK, W=0-------|Bitmap:11000001
	|-----W=0, CFN=4----->|MIC checked =>		|-----W=0, CFN=4----->|MIC checked =>
	(no ACK)		(no ACK)
	Figure 17: Transmission of an IPv6 packet carried by 11 fragments in		Figure 18: Transmission of an IPv6 packet carried by 11 fragments in
	Window mode - ACK on error, for N=3, three losses.		Window mode - ACK on error, for N=3, three losses.
	Figure 18 illustrates the transmission of an IPv6 packet that needs		Figure 19 illustrates the transmission of an IPv6 packet that needs
	11 fragments in Window mode - ACK "always", for N=3, without losses.		11 fragments in Window mode - ACK "always", for N=3, without losses.
	Note: in Window mode, an additional bit will be needed to number		Note: in Window mode, an additional bit will be needed to number
	windows.		windows.
	Sender Receiver		Sender Receiver
	|-----W=1, CFN=6----->|		|-----W=1, CFN=6----->|
	|-----W=1, CFN=5----->|		|-----W=1, CFN=5----->|
	|-----W=1, CFN=4----->|		|-----W=1, CFN=4----->|
	|-----W=1, CFN=3----->|		|-----W=1, CFN=3----->|
	|-----W=1, CFN=2----->|		|-----W=1, CFN=2----->|
	|-----W=1, CFN=1----->|		|-----W=1, CFN=1----->|
	|-----W=1, CFN=0----->|		|-----W=1, CFN=0----->|
	|<-----ACK, W=1-------|no bitmap		|<-----ACK, W=1-------|no bitmap
	|-----W=0, CFN=6----->|		|-----W=0, CFN=6----->|
	|-----W=0, CFN=5----->|		|-----W=0, CFN=5----->|
	|-----W=0, CFN=4----->|		|-----W=0, CFN=4----->|
	|-----W=0, CFN=7----->|MIC checked =>		|-----W=0, CFN=7----->|MIC checked =>
	|<-----ACK, W=0-------|no bitmap		|<-----ACK, W=0-------|no bitmap
	(End)		(End)
	Figure 18: Transmission of an IPv6 packet carried by 11 fragments in		Figure 19: Transmission of an IPv6 packet carried by 11 fragments in
	Window mode - ACK "always", for N=3, no losses.		Window mode - ACK "always", for N=3, no losses.
	Figure 19 illustrates the transmission of an IPv6 packet that needs		Figure 20 illustrates the transmission of an IPv6 packet that needs
	11 fragments in Window mode - ACK "always", for N=3, with three		11 fragments in Window mode - ACK "always", for N=3, with three
	losses.		losses.
	Sender Receiver		Sender Receiver
	|-----W=1, CFN=6----->|		|-----W=1, CFN=6----->|
	|-----W=1, CFN=5----->|		|-----W=1, CFN=5----->|
	|-----W=1, CFN=4--X-->|		|-----W=1, CFN=4--X-->|
	|-----W=1, CFN=3----->|		|-----W=1, CFN=3----->|
	|-----W=1, CFN=2--X-->|		|-----W=1, CFN=2--X-->|
	|-----W=1, CFN=1----->|		|-----W=1, CFN=1----->|
	skipping to change at page 35, line 30 ¶		skipping to change at page 36, line 30 ¶
	|<-----ACK, W=1-------|no bitmap		|<-----ACK, W=1-------|no bitmap
	|-----W=0, CFN=6----->|		|-----W=0, CFN=6----->|
	|-----W=0, CFN=5----->|		|-----W=0, CFN=5----->|
	|-----W=0, CFN=4--X-->|		|-----W=0, CFN=4--X-->|
	|-----W=0, CFN=7----->|MIC checked		|-----W=0, CFN=7----->|MIC checked
	|<-----ACK, W=0-------|bitmap:11000001		|<-----ACK, W=0-------|bitmap:11000001
	|-----W=0, CFN=4----->|MIC checked =>		|-----W=0, CFN=4----->|MIC checked =>
	|<-----ACK, W=0-------|no bitmap		|<-----ACK, W=0-------|no bitmap
	(End)		(End)
	Figure 19: Transmission of an IPv6 packet carried by 11 fragments in		Figure 20: Transmission of an IPv6 packet carried by 11 fragments in
	Window mode - ACK "Always", for N=3, with three losses.		Window mode - ACK "Always", for N=3, with three losses.
	Appendix B. Rule IDs for fragmentation		Appendix B. Rule IDs for fragmentation
	Different Rule IDs may be used for different aspects of fragmentation		Different Rule IDs may be used for different aspects of fragmentation
	functionality as per this document. A summary of such Rule IDs		functionality as per this document. A summary of such Rule IDs
	follows:		follows:
	o A fragment, and the reliability option in use for the IPv6		o A fragment, and the reliability option in use for the IPv6
	datagram being carried: i) No ACK, ii) Window mode - ACK on error,		datagram being carried: i) No ACK, ii) Window mode - ACK on error,
End of changes. 74 change blocks.
	217 lines changed or deleted		264 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/