< draft-ietf-lpwan-ipv6-static-context-hc-12.txt		draft-ietf-lpwan-ipv6-static-context-hc-13.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: November 19, 2018 IMT-Atlantique		Expires: November 23, 2018 IMT-Atlantique
	C. Gomez		C. Gomez
	Universitat Politecnica de Catalunya		Universitat Politecnica de Catalunya
	May 18, 2018		May 22, 2018
	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-12		draft-ietf-lpwan-ipv6-static-context-hc-13
	Abstract		Abstract
	This document defines the Static Context Header Compression (SCHC)		This document defines the Static Context Header Compression (SCHC)
	framework, which provides header compression and fragmentation		framework, which provides header compression and fragmentation
	functionality. SCHC has been tailored for Low Power Wide Area		functionality. SCHC has been tailored for Low Power Wide Area
	Networks (LPWAN).		Networks (LPWAN).
	SCHC compression is based on a common static context stored in both		SCHC compression is based on a common static context stored in both
	LPWAN devices and in the network sides. This document defines SCHC		LPWAN devices and in the network sides. This document defines SCHC
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 November 19, 2018.		This Internet-Draft will expire on November 23, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 13, line 40 ¶		skipping to change at page 13, line 40 ¶
	header.		header.
	The Rule also describes the Compression Residue sent regarding the		The Rule also describes the Compression Residue sent regarding the
	order of the Fields Descriptions in the Rule.		order of the Fields Descriptions in the Rule.
	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 Field ID (FID) is a unique value to define the header field.		o Field ID (FID) is a unique value to define the header field.
	o Field Length (FL) represents the length of the field in bits for		o Field Length (FL) represents the length of the field. It can be
	fixed values or a type (variable, token length, ...) for Field		either a fixed value (in bits) if the length is known when the
	Description length unknown at the rule creation. The length of a		rule is created or a type if the length is variable. The length
	header field is defined in the specific protocol standard.		of a header field is defined in the specific protocol standard.
			The type defines the process to compute length, its unit (bits,
			bytes,...) and the value to be sent before the compression
			residue.
	o Field Position (FP): indicating if several instances of a field		o Field Position (FP): indicating if several instances of a field
	exist in the headers which one is targeted. The default position		exist in the headers which one is targeted. The default position
	is 1.		is 1.
	o A direction indicator (DI) indicates the packet direction(s) this		o A direction indicator (DI) indicates the packet direction(s) this
	Field Description applies to. Three values are possible:		Field Description applies to. Three values are possible:
	* UPLINK (Up): this Field Description is only applicable to		* UPLINK (Up): this Field Description is only applicable to
	packets sent by the Dev to the App,		packets sent by the Dev to the App,
	skipping to change at page 15, line 41 ¶		skipping to change at page 15, line 45 ¶
	compressed header (with possibly a Compression Residue) SHOULD		compressed header (with possibly a Compression Residue) SHOULD
	be obtained. Otherwise, the next Rule is tested.		be obtained. Otherwise, the next Rule is tested.
	* If no eligible Rule is found, then the header MUST be sent		* If no eligible Rule is found, then the header MUST be sent
	without compression, depending on the L2 PDU size, this is one		without compression, depending on the L2 PDU size, this is one
	of the case that MAY require the use of the SCHC F/R process.		of the case that MAY require the use of the SCHC F/R process.
	o Sending: If an eligible Rule is found, the Rule ID is sent to the		o Sending: If an eligible Rule is found, the Rule ID is sent to the
	other end followed by the Compression Residue (which could be		other end followed by the Compression Residue (which could be
	empty) and directly followed by the payload. The Compression		empty) and directly followed by the payload. The Compression
	Residue is the concatenation of the Compression Residues for each		Residue is the concatenation of the Compression
	field according to the CDAs for that rule. The way the Rule ID is		Residues for each field according to the CDAs for that rule. The
	sent depends on the specific LPWAN layer two technology. For		way the Rule ID is sent depends on the specific LPWAN layer two
	example, it can be either included in a Layer 2 header or sent in		technology. For example, it can be either included in a Layer 2
	the first byte of the L2 payload. (Cf. Figure 9). This process		header or sent in the first byte of the L2 payload. (Cf.
	will be specified in the LPWAN technology-specific document and is		Figure 9). This process will be specified in the LPWAN
	out of the scope of the present document. On LPWAN technologies		technology-specific document and is out of the scope of the
	that are byte- oriented, the compressed header concatenated with		present document. On LPWAN technologies that are byte- oriented,
	the original packet payload is padded to a multiple of 8 bits, if		the compressed header concatenated with the original packet
	needed. See Section 8 for details.		payload is padded to a multiple of 8 bits, if needed. See
			Section 8 for details.
	o Decompression: When doing decompression, in the network side the		o Decompression: When doing decompression, in the network side the
	SCHC C/D needs to find the correct Rule based on the L2 address		SCHC C/D needs to find the correct Rule based on the L2 address
	and in this way, it can use the Dev-ID and the Rule-ID. In the		and in this way, it can use the Dev-ID and the Rule-ID. In the
	Dev side, only the Rule ID is needed to identify the correct Rule		Dev side, only the Rule ID is needed to identify the correct Rule
	since the Dev only holds Rules that apply to itself.		since the Dev only holds Rules that apply to itself.
	The receiver identifies the sender through its device-id (e.g.		The receiver identifies the sender through its device-id (e.g.
	MAC address, if exists) and selects the appropriate Rule		MAC address, if exists) and selects the appropriate Rule
	from the Rule ID. If a source identifier is present in the L2		from the Rule ID. If a source identifier is present in the L2
	skipping to change at page 16, line 46 ¶		skipping to change at page 16, line 50 ¶
	o equal: The match result is True if a field value in a packet and		o equal: The match result is True if a field value in a packet and
	the value in the TV are equal.		the value in the TV 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
	TV in the Rule. The result of the matching is always true.		TV in the Rule. The result of the matching is always true.
	o MSB(x): A match is obtained if the most significant x bits of the		o MSB(x): A match is obtained if the most significant x bits of the
	field value in the header packet are equal to the TV in the Rule.		field value in the header packet are equal to the TV in the Rule.
	The x parameter of the MSB Matching Operator indicates how many		The x parameter of the MSB Matching Operator indicates how many
	bits are involved in the comparison.		bits are involved in the comparison. If the FL is described as
			variable, the length must be a multiple of the unit. For example,
			x must be multiple of 8 if the unit of the variable length is in
			bytes.
	o match-mapping: With match-mapping, the Target Value is a list of		o match-mapping: With match-mapping, the Target Value is a list of
	values. Each value of the list is identified by a short ID (or		values. Each value of the list is identified by a short ID (or
	index). Compression is achieved by sending the index instead of		index). Compression is achieved by sending the index instead of
	the original header field value. This operator matches if the		the original header field value. This operator matches if the
	header field value is equal to one of the values in the target		header field value is equal to one of the values in the target
	list.		list.
	6.5. Compression Decompression Actions (CDA)		6.5. Compression Decompression Actions (CDA)
	skipping to change at page 17, line 42 ¶		skipping to change at page 17, line 50 ¶
	The second and third columns outline the reciprocal compression/		The second and third columns outline the reciprocal compression/
	decompression behavior for each action.		decompression behavior for each action.
	Compression is done in order that Fields Descriptions appear in the		Compression is done in order that Fields Descriptions appear in the
	Rule. The result of each Compression/Decompression Action is		Rule. The result of each Compression/Decompression Action is
	appended to the working Compression Residue in that same order. The		appended to the working Compression Residue in that same order. The
	receiver knows the size of each compressed field which can be given		receiver knows the size of each compressed field which can be given
	by the rule or MAY be sent with the compressed header.		by the rule or MAY be sent with the compressed header.
	If the field is identified as being variable in the Field		If the field is identified as being variable in the Field
	Description, then the size of the Compression Residue value in bytes		Description, then the size of the Compression Residue value (using
	MUST be sent first using the following coding:		the unit defined in the FL) MUST be sent first using the following
			coding:
	o If the size is between 0 and 14 bytes, it is sent as a 4-bits		o If the size is between 0 and 14 bytes, it is sent as a 4-bits
	integer.		integer.
	o For values between 15 and 254, the first 4 bits sent are set to 1		o For values between 15 and 254, the first 4 bits sent are set to 1
	and the size is sent using 8 bits integer.		and the size is sent using 8 bits integer.
	o For higher values of size, the first 12 bits are set to 1 and the		o For higher values of size, the first 12 bits are set to 1 and the
	next two bytes contain the size value as a 16 bits integer.		next two bytes contain the size value as a 16 bits integer.
	skipping to change at page 20, line 10 ¶		skipping to change at page 20, line 14 ¶
	o compute-checksum: computes a checksum from the information already		o compute-checksum: computes 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.
	7. Fragmentation		7. Fragmentation
	7.1. Overview		7.1. Overview
	In LPWAN technologies, the L2 data unit size typically varies from		In LPWAN technologies, the L2 data unit size typically varies from
	tens to hundreds of bytes. The SCHC Fragmentation /Reassembly MAY be		tens to hundreds of bytes. The SCHC F/R (Fragmentation /Reassembly)
	used either because after applying SCHC C/D or when SCHC C/D is not		MAY be used either because after applying SCHC C/D or when SCHC C/D
	possible the entire SCHC Packet still exceeds the L2 data unit.		is not possible the entire SCHC Packet still exceeds the L2 data
			unit.
	The SCHC F/R functionality defined in this document has been designed		The SCHC F/R functionality defined in this document has been designed
	under the assumption that data unit out-of- sequence delivery will		under the assumption that data unit out-of- sequence delivery will
	not happen between the entity performing fragmentation and the entity		not happen between the entity performing fragmentation and the entity
	performing reassembly. This assumption allows reducing the		performing reassembly. This assumption allows reducing the
	complexity and overhead of the SCHC F/R mechanism.		complexity and overhead of the SCHC F/R mechanism.
	To adapt the SCHC F/R to the capabilities of LPWAN technologies is		To adapt the SCHC F/R to the capabilities of LPWAN technologies is
	required to enable optional SCHC Fragment retransmission and to allow		required to enable optional SCHC Fragment retransmission and to allow
	a stepper delivery for the reliability of SCHC Fragments. This		a stepper delivery for the reliability of SCHC Fragments. This
	skipping to change at page 23, line 46 ¶		skipping to change at page 23, line 50 ¶
	o Padding (P). If it is needed, the number of bits used for padding		o Padding (P). If it is needed, the number of bits used for padding
	is not defined and depends on the size of the Rule ID, DTag and		is not defined and depends on the size of the Rule ID, DTag and
	FCN fields, and on the L2 payload size (see Section 8). Some SCHC		FCN fields, and on the L2 payload size (see Section 8). Some SCHC
	ACKs are byte-aligned and do not need padding (see		ACKs are byte-aligned and do not need padding (see
	Section 7.4.3.1).		Section 7.4.3.1).
	7.3. Reliability modes		7.3. Reliability modes
	This specification defines three reliability modes: No-ACK, ACK-		This specification defines three reliability modes: No-ACK, ACK-
	Always and ACK-on-Error. ACK-Always and ACK-on-Error operate on		Always, and ACK-on-Error. ACK-Always and ACK-on-Error operate on
	windows of SCHC Fragments. A window of SCHC Fragments is a subset of		windows of SCHC Fragments. A window of SCHC Fragments is a subset of
	the full set of SCHC Fragments needed to carry a packet or an SCHC		the full set of SCHC Fragments needed to carry a packet or an SCHC
	Packet.		Packet.
	o No-ACK. No-ACK is the simplest SCHC Fragment reliability mode.		o No-ACK. No-ACK is the simplest SCHC Fragment reliability mode.
	The receiver does not generate overhead in the form of		The receiver does not generate overhead in the form of
	acknowledgments (ACKs). However, this mode does not enhance		acknowledgments (ACKs). However, this mode does not enhance
	reliability beyond that offered by the underlying LPWAN		reliability beyond that offered by the underlying LPWAN
	technology. In the No-ACK mode, the receiver MUST NOT issue SCHC		technology. In the No-ACK mode, the receiver MUST NOT issue SCHC
	ACKs. See further details in Section 7.5.1.		ACKs. See further details in Section 7.5.1.
	skipping to change at page 24, line 24 ¶		skipping to change at page 24, line 29 ¶
	expense of SCHC ACK use. In ACK-Always the receiver sends an SCHC		expense of SCHC ACK use. In ACK-Always the receiver sends an SCHC
	ACK after a window of SCHC Fragments has been received, where a		ACK after a window of SCHC Fragments has been received, where a
	window of SCHC Fragments is a subset of the whole number of SCHC		window of SCHC Fragments is a subset of the whole number of SCHC
	Fragments needed to carry a complete SCHC Packet. The SCHC ACK is		Fragments needed to carry a complete SCHC Packet. The SCHC ACK is
	used to inform the sender if a SCHC fragment in the actual window		used to inform the sender if a SCHC fragment in the actual window
	has been lost or well received. Upon an SCHC ACK reception, the		has been lost or well received. Upon an SCHC ACK reception, the
	sender retransmits the lost SCHC Fragments. When an SCHC ACK is		sender retransmits the lost SCHC Fragments. When an SCHC ACK is
	lost and the sender has not received it before the expiration of		lost and the sender has not received it before the expiration of
	the Retransmission Timer, the sender uses an SCHC ACK request by		the Retransmission Timer, the sender uses an SCHC ACK request by
	sending the All-0 empty SCHC Fragment when it is not the last		sending the All-0 empty SCHC Fragment when it is not the last
	windown and the ALL-1 empty Fragment when it is the last window.		window and the ALL-1 empty Fragment when it is the last window.
	The maximum number of SCHC ACK requests is MAX_ACK_REQUESTS. If		The maximum number of SCHC ACK requests is MAX_ACK_REQUESTS. If
	the MAX_ACK_REQUEST is reached the transmission needs to be		the MAX_ACK_REQUEST is reached the transmission needs to be
	Aborted. See further details in Section 7.5.2.		Aborted. See further details in Section 7.5.2.
	o ACK-on-Error. The ACK-on-Error mode is suitable for links		o ACK-on-Error. The ACK-on-Error mode is suitable for links
	offering relatively low L2 data unit loss probability. In this		offering relatively low L2 data unit loss probability. In this
	mode, the SCHC Fragment receiver reduces the number of SCHC ACKs		mode, the SCHC Fragment receiver reduces the number of SCHC ACKs
	transmitted, which MAY be especially beneficial in asymmetric		transmitted, which MAY be especially beneficial in asymmetric
	scenarios. Because the SCHC Fragments use the uplink of the		scenarios. Because the SCHC Fragments use the uplink of the
	underlying LPWAN technology, which has higher capacity than		underlying LPWAN technology, which has higher capacity than
	skipping to change at page 28, line 45 ¶		skipping to change at page 28, line 45 ¶
	C		C
	Figure 20: Format of an SCHC ACK for All-1 windows		Figure 20: Format of an SCHC ACK for All-1 windows
	7.4.3.1. Bitmap Encoding		7.4.3.1. Bitmap Encoding
	The Bitmap is transmitted by a receiver as part of the SCHC ACK		The Bitmap is transmitted by a receiver as part of the SCHC ACK
	format. An SCHC ACK message MAY include padding at the end to align		format. An SCHC ACK message MAY include padding at the end to align
	its number of transmitted bits to a multiple of 8 bits.		its number of transmitted bits to a multiple of 8 bits.
	Note that the SCHC ACK sent in response to an All-1 fragment includes		Note that the SCHC ACK sent a response to an All-1 fragment including
	the C bit. Therefore, the window size and thus the encoded Bitmap		the C bit. Therefore, the window size and thus the encoded Bitmap
	size need to be determined taking into account the available space in		size need to be determined to take into account the available space
	the layer two frame payload, where there will be 1 bit less for an		in the layer two frame payload, where there will be 1 bit less for an
	SCHC ACK sent in response to an All-1 fragment than in other SCHC		SCHC ACK sent in response to an All-1 fragment than in other SCHC
	ACKs. Note that the maximum number of SCHC Fragments of the last		ACKs. Note that the maximum number of SCHC Fragments of the last
	window is one unit smaller than that of the previous windows.		window is one unit smaller than that of the previous windows.
	When the receiver transmits an encoded Bitmap with a SCHC Fragment		When the receiver transmits an encoded Bitmap with a SCHC Fragment
	that has not been sent during the transmission, the sender will Abort		that has not been sent during the transmission, the sender will Abort
	the transmission.		the transmission.
	|---- Bitmap bits ----|		|---- Bitmap bits ----|
	| Rule ID | DTag |W|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|		| Rule ID | DTag |W|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|
	|--- byte boundary ----| 1 byte next | 1 byte next |		|--- byte boundary ----| 1 byte next | 1 byte next |
	Figure 21: A non-encoded Bitmap		Figure 21: A non-encoded Bitmap
	In order to reduce the resulting frame size, the encoded Bitmap is		In order to reduce the resulting frame size, the encoded Bitmap is
	shortened by applying the following algorithm: all the right-most		shortened by applying the following algorithm: all the right-most
	contiguous bytes in the encoded Bitmap that have all their bits set		contiguous bytes in the encoded Bitmap that have all their bits set
	to 1 MUST NOT be transmitted. Because the SCHC Fragment sender knows		to 1 MUST NOT be transmitted. Because the SCHC Fragment sender knows
	the actual Bitmap size, it can reconstruct the original Bitmap with		the actual Bitmap size, it can reconstruct the original Bitmap with
	the trailing 1 bit optimized away. In the example shown in		the trailing 1 bit optimized away. In the example shown in
	Figure 22, the last 2 bytes of the Bitmap shown in Figure 21 comprise		Figure 22, the last 2 bytes of the Bitmap shown in Figure 21
	bits that are all set to 1, therefore they are not sent.		comprises bits that are all set to 1, therefore they are not sent.
	|-- T --|1|		|-- T --|1|
	+---- ... --+- ... -+-+-+-+		+---- ... --+- ... -+-+-+-+
	| Rule ID | DTag |W|1|0|		| Rule ID | DTag |W|1|0|
	+---- ... --+- ... -+-+-+-+		+---- ... --+- ... -+-+-+-+
	|---- byte boundary -----|		|---- byte boundary -----|
	Figure 22: Optimized Bitmap format		Figure 22: Optimized Bitmap format
	Figure 23 shows an example of an SCHC ACK with FCN ranging from 6		Figure 23 shows an example of an SCHC ACK with FCN ranging from 6
End of changes. 14 change blocks.
	31 lines changed or deleted		40 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/