< draft-ietf-lpwan-ipv6-static-context-hc-15.txt		draft-ietf-lpwan-ipv6-static-context-hc-16.txt >
	skipping to change at page 1, line 15 ¶		skipping to change at page 1, line 15 ¶
	Intended status: Standards Track L. Toutain		Intended status: Standards Track L. Toutain
	Expires: December 31, 2018 IMT-Atlantique		Expires: December 31, 2018 IMT-Atlantique
	C. Gomez		C. Gomez
	Universitat Politecnica de Catalunya		Universitat Politecnica de Catalunya
	D. Barthel		D. Barthel
	Orange Labs		Orange Labs
	June 29, 2018		June 29, 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-15		draft-ietf-lpwan-ipv6-static-context-hc-16
	Abstract		Abstract
	This document defines the Static Context Header Compression (SCHC)		This document defines the Static Context Header Compression (SCHC)
	framework, which provides both header compression and fragmentation		framework, which provides both header compression and fragmentation
	functionalities. SCHC has been tailored for Low Power Wide Area		functionalities. 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
	the LPWAN devices and the network side. This document defines a		the LPWAN devices and the network side. This document defines a
	skipping to change at page 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	8.3. Reliability modes . . . . . . . . . . . . . . . . . . . . 25		8.3. Reliability modes . . . . . . . . . . . . . . . . . . . . 25
	8.4. Fragmentation Formats . . . . . . . . . . . . . . . . . . 27		8.4. Fragmentation Formats . . . . . . . . . . . . . . . . . . 27
	8.4.1. Fragments that are not the last one . . . . . . . . . 27		8.4.1. Fragments that are not the last one . . . . . . . . . 27
	8.4.2. All-1 fragment . . . . . . . . . . . . . . . . . . . 29		8.4.2. All-1 fragment . . . . . . . . . . . . . . . . . . . 29
	8.4.3. SCHC ACK format . . . . . . . . . . . . . . . . . . . 31		8.4.3. SCHC ACK format . . . . . . . . . . . . . . . . . . . 31
	8.4.4. Abort formats . . . . . . . . . . . . . . . . . . . . 33		8.4.4. Abort formats . . . . . . . . . . . . . . . . . . . . 33
	8.5. Baseline mechanism . . . . . . . . . . . . . . . . . . . 35		8.5. Baseline mechanism . . . . . . . . . . . . . . . . . . . 35
	8.5.1. No-ACK . . . . . . . . . . . . . . . . . . . . . . . 36		8.5.1. No-ACK . . . . . . . . . . . . . . . . . . . . . . . 36
	8.5.2. ACK-Always . . . . . . . . . . . . . . . . . . . . . 36		8.5.2. ACK-Always . . . . . . . . . . . . . . . . . . . . . 36
	8.5.3. ACK-on-Error . . . . . . . . . . . . . . . . . . . . 39		8.5.3. ACK-on-Error . . . . . . . . . . . . . . . . . . . . 39
	8.6. Supporting multiple window sizes . . . . . . . . . . . . 41		8.6. Supporting multiple window sizes . . . . . . . . . . . . 40
	8.7. Downlink SCHC Fragment transmission . . . . . . . . . . . 41		8.7. Downlink SCHC Fragment transmission . . . . . . . . . . . 41
	9. Padding management . . . . . . . . . . . . . . . . . . . . . 42		9. Padding management . . . . . . . . . . . . . . . . . . . . . 42
	10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 43		10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 43
	10.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 43		10.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 43
	10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 43		10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 43
	10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 44		10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 44
	10.4. Payload Length field . . . . . . . . . . . . . . . . . . 44		10.4. Payload Length field . . . . . . . . . . . . . . . . . . 44
	10.5. Next Header field . . . . . . . . . . . . . . . . . . . 44		10.5. Next Header field . . . . . . . . . . . . . . . . . . . 44
	10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 45		10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 45
	10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 45		10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 45
	skipping to change at page 5, line 13 ¶		skipping to change at page 5, line 13 ¶
	reassembly.		reassembly.
	Note that this document defines generic functionality and		Note that this document defines generic functionality and
	purposefully offers flexibility with regard to parameter settings and		purposefully offers flexibility with regard to parameter settings and
	mechanism choices. Such settings and choices are expected to be made		mechanism choices. Such settings and choices are expected to be made
	in other, technology-specific documents.		in other, technology-specific documents.
	2. Requirements Notation		2. Requirements Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. LPWAN Architecture		3. LPWAN Architecture
	LPWAN technologies have similar network architectures but different		LPWAN technologies have similar network architectures but different
	terminologies. Using the terminology defined in [RFC8376], we can		terminologies. Using the terminology defined in [RFC8376], we can
	identify different types of entities in a typical LPWAN network, see		identify different types of entities in a typical LPWAN network, see
	Figure 1:		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,
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 5 ¶
	As per this document, when a packet (e.g. an IPv6 packet) needs to be		As per this document, when a packet (e.g. an IPv6 packet) needs to be
	transmitted, header compression is first applied to the packet. The		transmitted, header compression is first applied to the packet. The
	resulting packet after header compression (whose header may or may		resulting packet after header compression (whose header may or may
	not actually be smaller than that of the original packet) is called a		not actually be smaller than that of the original packet) is called a
	SCHC Packet. If the SCHC Packet size exceeds the layer 2 (L2) MTU,		SCHC Packet. If the SCHC Packet size exceeds the layer 2 (L2) MTU,
	fragmentation is then applied to the SCHC Packet. The SCHC Packet or		fragmentation is then applied to the SCHC Packet. The SCHC Packet or
	the SCHC Fragments are then transmitted over the LPWAN. The		the SCHC Fragments are then transmitted over the LPWAN. The
	reciprocal operations take place at the receiver. This process is		reciprocal operations take place at the receiver. This process is
	illustrated in Figure 3.		illustrated in Figure 3.
	A packet (e.g. an IPv6 packet)		A packet (e.g. an IPv6 packet)
	| ^		| ^
	v |		v |
	+------------------+ +--------------------+		+------------------+ +--------------------+
	| SCHC Compression | | SCHC Decompression |		| SCHC Compression | | SCHC Decompression |
	+------------------+ +--------------------+		+------------------+ +--------------------+
	| ^		| ^
	| If no fragmentation (*) |		| If no fragmentation (*) |
	+-------------- SCHC Packet -------------->|		+-------------- SCHC Packet -------------->|
	| |		| |
	v |		v |
	+--------------------+ +-----------------+		+--------------------+ +-----------------+
	| SCHC Fragmentation | | SCHC Reassembly |		| SCHC Fragmentation | | SCHC Reassembly |
	+--------------------+ +-----------------+		+--------------------+ +-----------------+
	| ^ | ^		| ^ | ^
	| | | |		| | | |
	| +-------------- SCHC ACK -------------+ |		| +-------------- SCHC ACK -------------+ |
	| |		| |
	+-------------- SCHC Fragments -------------------+		+-------------- SCHC Fragments -------------------+
	SENDER RECEIVER		SENDER RECEIVER
	*: the decision to use Fragmentation or not is left to each LPWAN technology		*: the decision to use Fragmentation or not is left to each LPWAN
	over which SCHC is applied. See LPWAN technology-specific documents.		technology over which SCHC is applied. See LPWAN
			technology-specific documents.
	Figure 3: SCHC operations taking place at the sender and the receiver		Figure 3: SCHC operations taking place at the sender and the receiver
	The SCHC Packet is composed of the Compressed Header followed by the		The SCHC Packet is composed of the Compressed Header followed by the
	payload from the original packet (see Figure 4). The Compressed		payload from the original packet (see Figure 4). The Compressed
	Header itself is composed of a Rule ID and a Compression Residue.		Header itself is composed of a Rule ID and a Compression Residue.
	The Compression Residue may be absent, see Section 7. Both the Rule		The Compression Residue may be absent, see Section 7. Both the Rule
	ID and the Compression Residue potentially have a variable size, and		ID and the Compression Residue potentially have a variable size, and
	generally are not a mutiple of bytes in size.		generally are not a mutiple of bytes in size.
	skipping to change at page 34, line 35 ¶		skipping to change at page 34, line 35 ¶
	a Receiver-Abort is coded as a SCHC ACK message with a shortened		a Receiver-Abort is coded as a SCHC ACK message with a shortened
	Bitmap set to 1 up to the first L2 Word boundary, followed by an		Bitmap set to 1 up to the first L2 Word boundary, followed by an
	extra L2 Word full of 1's. Such a message never occurs in a regular		extra L2 Word full of 1's. Such a message never occurs in a regular
	acknowledgement and is detected as a Receiver-Abort.		acknowledgement and is detected as a Receiver-Abort.
	The Rule ID and Dtag values in the Receive-Abort message MUST be		The Rule ID and Dtag values in the Receive-Abort message MUST be
	identical to the ones used in the fragments of the SCHC Packet the		identical to the ones used in the fragments of the SCHC Packet the
	transmission of which is being aborted.		transmission of which is being aborted.
	A Receiver-Abort is aligned to L2 Words, by design. Therefore,		A Receiver-Abort is aligned to L2 Words, by design. Therefore,
	padding MUST not be appended.		padding MUST NOT be appended.
	|- Receiver-Abort Header -|		|- Receiver-Abort Header -|
	+---- ... ----+-- ... --+-+-+-+-+-+-+-+-+-+-+-+-+		+---- ... ----+-- ... --+-+-+-+-+-+-+-+-+-+-+-+-+
	| Rule ID | DTag |W| 1..1| 1..1 |		| Rule ID | DTag |W| 1..1| 1..1 |
	+---- ... ----+-- ... --+-+-+-+-+-+-+-+-+-+-+-+-+		+---- ... ----+-- ... --+-+-+-+-+-+-+-+-+-+-+-+-+
	next L2 Word boundary ->|<-- L2 Word -->|		next L2 Word boundary ->|<-- L2 Word -->|
	Figure 26: Receiver-Abort format		Figure 26: Receiver-Abort format
	skipping to change at page 38, line 16 ¶		skipping to change at page 38, line 16 ¶
	managed by the receiver is computed based on the FCN value. The		managed by the receiver is computed based on the FCN value. The
	receiver prepares the encoded Bitmap to report the correctly received		receiver prepares the encoded Bitmap to report the correctly received
	and the missing SCHC Fragments for the current window. After each		and the missing SCHC Fragments for the current window. After each
	SCHC Fragment is received, the receiver initializes the Inactivity		SCHC Fragment is received, the receiver initializes the Inactivity
	Timer. When the Inactivity Timer expires, the transmission is		Timer. When the Inactivity Timer expires, the transmission is
	aborted by the receiver sending a Receiver-Abort message.		aborted by the receiver sending a Receiver-Abort message.
	When an All-0 fragment is received, it indicates that all the SCHC		When an All-0 fragment is received, it indicates that all the SCHC
	Fragments have been sent in the current window. Since the sender is		Fragments have been sent in the current window. Since the sender is
	not obliged to always send a full window, some SCHC Fragment number		not obliged to always send a full window, some SCHC Fragment number
	not set in the receiver memory SHOULD not correspond to losses. The		not set in the receiver memory may not correspond to losses. The
	receiver sends the corresponding SCHC ACK, the Inactivity Timer is		receiver sends the corresponding SCHC ACK, the Inactivity Timer is
	set and the transmission of the next window by the sender can start.		set and the transmission of the next window by the sender can start.
	If an All-0 fragment has been received and all SCHC Fragments of the		If an All-0 fragment has been received and all SCHC Fragments of the
	current window have also been received, the receiver then expects a		current window have also been received, the receiver then expects a
	new Window and waits for the next SCHC Fragment. Upon receipt of a		new Window and waits for the next SCHC Fragment. Upon receipt of a
	SCHC Fragment, if the window value has not changed, the received SCHC		SCHC Fragment, if the window value has not changed, the received SCHC
	Fragments are part of a retransmission. A receiver that has already		Fragments are part of a retransmission. A receiver that has already
	received a SCHC Fragment SHOULD discard it, otherwise, it updates the		received a SCHC Fragment SHOULD discard it, otherwise, it updates the
	encoded Bitmap. If all the bits of the encoded Bitmap are set to		Bitmap. If all the bits of the Bitmap are set to one, the receiver
	one, the receiver MUST send a SCHC ACK without waiting for an All-0		MUST send a SCHC ACK without waiting for an All-0 fragment and the
	fragment and the Inactivity Timer is initialized.		Inactivity Timer is initialized.
	On the other hand, if the window value of the next received SCHC		On the other hand, if the window value of the next received SCHC
	Fragment is set to the next expected window value, this means that		Fragment is set to the next expected window value, this means that
	the sender has received a correct encoded Bitmap reporting that all		the sender has received a correct encoded Bitmap reporting that all
	SCHC Fragments have been received. The receiver then updates the		SCHC Fragments have been received. The receiver then updates the
	value of the next expected window.		value of the next expected window.
	When an All-1 fragment is received, it indicates that the last SCHC		When an All-1 fragment is received, it indicates that the last SCHC
	Fragment of the packet has been sent. Since the last window is not		Fragment of the packet has been sent. Since the last window is not
	always full, the MIC will be used by the receiver to detect if all		always full, the MIC will be used by the receiver to detect if all
	skipping to change at page 39, line 27 ¶		skipping to change at page 39, line 27 ¶
	transmission.		transmission.
	In ACK-on-Error, the Retransmission Timer expiration is considered as		In ACK-on-Error, the Retransmission Timer expiration is considered as
	a positive acknowledgement for all windows but the last one. This		a positive acknowledgement for all windows but the last one. This
	timer is set after sending an All-0 or an All-1 fragment. For an		timer is set after sending an All-0 or an All-1 fragment. For an
	All-0 fragment, on timer expiration, the sender resumes operation and		All-0 fragment, on timer expiration, the sender resumes operation and
	sends the SCHC Fragments of the next window.		sends the SCHC Fragments of the next window.
	If the sender receives a SCHC ACK, it checks the window value. SCHC		If the sender receives a SCHC ACK, it checks the window value. SCHC
	ACKs with an unexpected window number are discarded. If the window		ACKs with an unexpected window number are discarded. If the window
	number on the received encoded Bitmap is correct, the sender verifies		number in the received SCHC ACK is correct, the sender verifies if
	if the receiver has received all SCHC fragments of the current		the receiver has received all SCHC fragments of the current window.
	window. When at least one SCHC Fragment has been lost, the counter		When at least one SCHC Fragment has been lost, the counter Attempts
	Attempts is increased by one and the sender resends the missing SCHC		is increased by one and the sender resends the missing SCHC Fragments
	Fragments again. When Attempts reaches MAX_ACK_REQUESTS, the sender		again. When Attempts reaches MAX_ACK_REQUESTS, the sender sends a
	sends a Sender-Abort message and releases all resources for the on-		Sender-Abort message and releases all resources for the on-going
	going fragmented SCHC Packet transmission. When the retransmission		fragmented SCHC Packet transmission. When the retransmission of the
	of the missing SCHC Fragments is finished, the sender starts		missing SCHC Fragments is finished, the sender starts listening for a
	listening for a SCHC ACK (even if an All-0 or an All-1 has not been		SCHC ACK (even if an All-0 or an All-1 has not been sent during the
	sent during the retransmission) and initializes the Retransmission		retransmission) and initializes the Retransmission Timer.
	Timer.
	After sending an All-1 fragment, the sender listens for a SCHC ACK,		After sending an All-1 fragment, the sender listens for a SCHC ACK,
	initializes Attempts, and starts the Retransmission Timer. If the		initializes Attempts, and starts the Retransmission Timer. If the
	Retransmission Timer expires, Attempts is increased by one and an		Retransmission Timer expires, Attempts is increased by one and an
	empty All-1 fragment is sent to request the SCHC ACK for the last		empty All-1 fragment is sent to request the SCHC ACK for the last
	window. If Attempts reaches MAX_ACK_REQUESTS, the sender aborts the		window. If Attempts reaches MAX_ACK_REQUESTS, the sender aborts the
	on-going fragmented SCHC Packet transmission by transmitting the		on-going fragmented SCHC Packet transmission by transmitting the
	Sender-Abort fragment.		Sender-Abort fragment.
	At the end of any window, if the sender receives a SCK ACK with a		At the end of any window, if the sender receives a SCK ACK with a
End of changes. 11 change blocks.
	42 lines changed or deleted		42 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/