< draft-ietf-lpwan-schc-over-lorawan-01.txt		draft-ietf-lpwan-schc-over-lorawan-02.txt >
	lpwan Working Group O. Gimenez, Ed.		lpwan Working Group O. Gimenez, Ed.
	Internet-Draft Semtech		Internet-Draft Semtech
	Intended status: Informational I. Petrov, Ed.		Intended status: Informational I. Petrov, Ed.
	Expires: December 28, 2019 Acklio		Expires: January 9, 2020 Acklio
	June 26, 2019		July 08, 2019
	Static Context Header Compression (SCHC) over LoRaWAN		Static Context Header Compression (SCHC) over LoRaWAN
	draft-ietf-lpwan-schc-over-lorawan-01		draft-ietf-lpwan-schc-over-lorawan-02
	Abstract		Abstract
	The Static Context Header Compression (SCHC) specification describes		The Static Context Header Compression (SCHC) specification describes
	generic header compression and fragmentation techniques for LPWAN		generic header compression and fragmentation techniques for LPWAN
	(Low Power Wide Area Networks) technologies. SCHC is a generic		(Low Power Wide Area Networks) technologies. SCHC is a generic
	mechanism designed for great flexibility, so that it can be adapted		mechanism designed for great flexibility, so that it can be adapted
	for any of the LPWAN technologies.		for any of the LPWAN technologies.
	This document provides the adaptation of SCHC for use in LoRaWAN		This document provides the adaptation of SCHC for use in LoRaWAN
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 December 28, 2019.		This Internet-Draft will expire on January 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	6. Security considerations . . . . . . . . . . . . . . . . . . . 16		6. Security considerations . . . . . . . . . . . . . . . . . . . 16
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9.1. Normative References . . . . . . . . . . . . . . . . . . 17		9.1. Normative References . . . . . . . . . . . . . . . . . . 17
	9.2. Informative References . . . . . . . . . . . . . . . . . 18		9.2. Informative References . . . . . . . . . . . . . . . . . 18
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18
	A.1. Uplink - Compression example - No fragmentation . . . . . 18		A.1. Uplink - Compression example - No fragmentation . . . . . 18
	A.2. Uplink - Compression and fragmentation example . . . . . 19		A.2. Uplink - Compression and fragmentation example . . . . . 19
	A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 20		A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 20
	Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 20		Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	The Static Context Header Compression (SCHC) specification		The Static Context Header Compression (SCHC) specification
	[I-D.ietf-lpwan-ipv6-static-context-hc] describes generic header		[I-D.ietf-lpwan-ipv6-static-context-hc] describes generic header
	compression and fragmentation techniques that can be used on all		compression and fragmentation techniques that can be used on all
	LPWAN (Low Power Wide Area Networks) technologies defined in		LPWAN (Low Power Wide Area Networks) technologies defined in
	[RFC8376]. Even though those technologies share a great number of		[RFC8376]. Even though those technologies share a great number of
	common features like star-oriented topologies, network architecture,		common features like star-oriented topologies, network architecture,
	devices with mostly quite predictable communications, etc; they do		devices with mostly quite predictable communications, etc; they do
	skipping to change at page 11, line 36 ¶		skipping to change at page 11, line 36 ¶
	| DTag | FCN | Payload |		| DTag | FCN | Payload |
	+ ----- + ------ + ------- +		+ ----- + ------ + ------- +
	| 1 bit | 7 bits | |		| 1 bit | 7 bits | |
	Figure 5: All fragment except the last one. Header size is 8 bits (1		Figure 5: All fragment except the last one. Header size is 8 bits (1
	byte).		byte).
	*SCHC ACK*		*SCHC ACK*
	| RuleID | DTag | W | C | Encoded bitmap (if C = 0) | Padding (0s) |		| DTag | C | Encoded bitmap (if C = 0) | Padding (0s) |
	+ ------ + ----- + ----- + ----- + ------------------------- + ------------ +		+ ----- + ----- + ------------------------- + ------------ +
	| 6 bits | 1 bit | 2 bit | 1 bit | 0 to 127 bits | 7 or 0 bits |		| 1 bit | 1 bit | 0 to 127 bits | 7 or 0 bits |
	Figure 6: SCHC ACK format, failed mic check.		Figure 6: SCHC ACK format, failed mic check.
	5.5.1.2. FPortUpDefault - 2 bytes header		5.5.1.2. FPortUpDefault - 2 bytes header
	o *RuleID*: size is 6 bits (64 possible rules, 62 available for		o *RuleID*: size is 6 bits (64 possible rules, 62 available for
	compression)		compression)
	o *Window index*: encoded on W = 2 bits. So 4 windows are		o *Window index*: encoded on W = 2 bits. So 4 windows are
	available.		available.
	skipping to change at page 18, line 31 ¶		skipping to change at page 18, line 31 ¶
	February 2014, <https://www.rfc-editor.org/info/rfc7136>.		February 2014, <https://www.rfc-editor.org/info/rfc7136>.
	[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)		[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
	Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,		Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
	<https://www.rfc-editor.org/info/rfc8376>.		<https://www.rfc-editor.org/info/rfc8376>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-lpwan-ipv6-static-context-hc]		[I-D.ietf-lpwan-ipv6-static-context-hc]
	Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.		Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
	Zuniga, "LPWAN Static Context Header Compression (SCHC)		Zuniga, "Static Context Header Compression (SCHC) and
	and fragmentation for IPv6 and UDP", draft-ietf-lpwan-		fragmentation for LPWAN, application to UDP/IPv6", draft-
	ipv6-static-context-hc-18 (work in progress), December		ietf-lpwan-ipv6-static-context-hc-19 (work in progress),
	2018.		July 2019.
	[lora-alliance-spec]		[lora-alliance-spec]
	Alliance, L., "LoRaWAN Specification Version V1.0.3",		Alliance, L., "LoRaWAN Specification Version V1.0.3",
	<https://lora-alliance.org/sites/default/files/2018-07/		<https://lora-alliance.org/sites/default/files/2018-07/
	lorawan1.0.3.pdf>.		lorawan1.0.3.pdf>.
	Appendix A. Examples		Appendix A. Examples
	A.1. Uplink - Compression example - No fragmentation		A.1. Uplink - Compression example - No fragmentation
	Figure 16 is representing an applicative payload going through SCHC,		Figure 16 is representing an applicative payload going through SCHC,
	no fragmentation required		no fragmentation required
	An applicative payload of 78 bytes is passed to SCHC compression layer using		An applicative payload of 78 bytes is passed to SCHC compression layer using
	rule 1, allowing to compress it to 40 bytes: 2 bytes residue + 38 bytes		rule 1, allowing to compress it to 40 bytes and 5 bits: 21 bits residue + 38 bytes
	payload.		payload.
	| RuleID | Compression residue | Payload |		| RuleID | Compression residue | Payload | Padding=0b000 |
	+ ------ + ------------------- + --------- +		+ ------ + ------------------- + --------- + ------------- +
	| 1 | 18 bits | 38 bytes |		| 1 | 21 bits | 38 bytes | 3 bits |
	The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used by		The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used by
	LoRaWAN protocol: 49 bytes are available for SCHC payload; no need for		LoRaWAN protocol: 49 bytes are available for SCHC payload; no need for
	fragmentation. The payload will be transmitted through FPortUpDefault		fragmentation. The payload will be transmitted through FPortUpDefault
	| LoRaWAN Header | RuleID | Compression residue | Payload |		| LoRaWAN Header | RuleID | Compression residue | Payload | Padding=b'000 |
	+ -------------- + ------ + ------------------- + --------- +		+ -------------- + ------ + ------------------- + --------- + ------------- +
	| XXXX | 1 | 18 bits | 38 bytes |		| XXXX | 1 | 21 bits | 38 bytes | 3 bits |
	Figure 16: Uplink example: compression without fragmentation		Figure 16: Uplink example: compression without fragmentation
	A.2. Uplink - Compression and fragmentation example		A.2. Uplink - Compression and fragmentation example
	Figure 17 is representing an applicative payload going through SCHC,		Figure 17 is representing an applicative payload going through SCHC,
	with fragmentation.		with fragmentation.
	An applicative payload of 478 bytes is passed to SCHC compression layer using		An applicative payload of 478 bytes is passed to SCHC compression layer using
	rule 1, allowing to compress it to 440 bytes: 18 bits residue + 138 bytes		rule 1, allowing to compress it to 440 bytes: 21 bits residue + 138 bytes
	payload.		payload.
	| RuleID | Compression residue | Payload |		| RuleID | Compression residue | Payload |
	+ ------ + ------------------- + --------- +		+ ------ + ------------------- + --------- +
	| 1 | 18 bits | 138 bytes |		| 1 | 21 bits | 138 bytes |
	Given the size of the payload, FPortUpDefault will be used.		Given the size of the payload, FPortUpDefault will be used.
	The current LoRaWAN MTU is 11 bytes, although 2 bytes FOpts are used by		The current LoRaWAN MTU is 11 bytes, although 2 bytes FOpts are used by
	LoRaWAN protocol: 9 bytes are available for SCHC payload.		LoRaWAN protocol: 9 bytes are available for SCHC payload.
	SCHC header is 2 bytes so 2 tiles are send in first fragment.		SCHC header is 2 bytes so 2 tiles are send in first fragment.
	| LoRaWAN Header | FOpts | RuleID | DTag | W | FCN | 2 tiles |		| LoRaWAN Header | FOpts | RuleID | DTag | W | FCN | 2 tiles |
	+ -------------- + ------- + ------ + ----- + ------ + ------ + ------- +		+ -------------- + ------- + ------ + ----- + ------ + ------ + ------- +
	| XXXX | 2 bytes | 0 | 0 | 0 | 126 | 6 bytes |		| XXXX | 2 bytes | 0 | 0 | 0 | 126 | 6 bytes |
	Content of the two tiles is:		Content of the two tiles is:
	| RuleID | Compression residue | Payload |		| RuleID | Compression residue | Payload |
	+ ------ + ------------------- + --------- +		+ ------ + ------------------- + ------------------ +
	| 1 | 18 bits | 3 bytes |		| 1 | 21 bits | 2 bytes + 5 bits |
	Next transmission MTU is 242 bytes, no FOpts. 80 tiles are transmitted:		Next transmission MTU is 242 bytes, no FOpts. 80 tiles are transmitted:
	| LoRaWAN Header | RuleID | DTag | W | FCN | 80 tiles |		| LoRaWAN Header | RuleID | DTag | W | FCN | 80 tiles |
	+ -------------- + ------ + ----- + ------ + ------ + --------- +		+ -------------- + ------ + ----- + ------ + ------ + --------- +
	| XXXX | 0 | 0 | 0 | 124 | 240 bytes |		| XXXX | 0 | 0 | 0 | 124 | 240 bytes |
	Next transmission MTU is 242 bytes, no FOpts. All 65 remaining tiles are		Next transmission MTU is 242 bytes, no FOpts. All 65 remaining tiles are
	transmitted, last tile is only 2 bytes.		transmitted, last tile is only 2 bytes. Padding is added for the remaining 6 bits.
	| LoRaWAN Header | RuleID | DTag | W | FCN | MIC | 65 tiles |		| LoRaWAN Header | RuleID | DTag | W | FCN | MIC | 65 tiles | Padding=b'000 |
	+ -------------- + ------ + ----- + ------ + ------ + ----- + --------- +		+ -------------- + ------ + ----- + ------ + ------ + ----- + --------- + ---------------- +
	| XXXX | 0 | 0 | 0 | 127 | CRC32 | 194 bytes |		| XXXX | 0 | 0 | 0 | 127 | CRC32 | 194 bytes | 3 bits |
	All packets have been received by the SCHC gateway, computed MIC is correct so		All packets have been received by the SCHC gateway, computed MIC is correct so
	the following ACK is send to the device:		the following ACK is send to the device:
	| LoRaWAN Header | RuleID | DTag | W | C |		| LoRaWAN Header | RuleID | DTag | W | C |
	+ -------------- + ------ + ----- + ------ + --- +		+ -------------- + ------ + ----- + ------ + --- +
	| XXXX | 0 | 0 | 0 | 1 |		| XXXX | 0 | 0 | 0 | 1 |
	Figure 17: Uplink example: compression and fragmentation		Figure 17: Uplink example: compression and fragmentation
	A.3. Downlink		A.3. Downlink
	TODO		An applicative payload of 43 bytes is passed to SCHC compression layer using
			rule 1, allowing to compress it to 24 bytes and 5 bits: 21 bits residue + 22 bytes
			payload.
			| RuleID | Compression residue | Payload |
			+ ------ + ------------------- + --------- +
			| 1 | 21 bits | 18 bytes |
			The current LoRaWAN MTU is 11 bytes, although 2 bytes FOpts are used by
			LoRaWAN protocol: 9 bytes are available for SCHC payload => it has to be fragmented.
			| LoRaWAN Header | FOpts | RuleID | W | FCN | 1 tile |
			+ -------------- + ------- + ------ + ------ + ------ + ------- +
			| XXXX | 2 bytes | 0 | 0 | 0 | 8 bytes |
			Content of the two tiles is:
			| RuleID | Compression residue | Payload |
			+ ------ + ------------------- + ------------------ +
			| 1 | 21 bits | 2 bytes + 5 bits |
			The receiver answers with an SCHC ACK
			| RuleID | W = 0 | C = b'1 |
			+ ------ + ----- + ------- +
			| 6 bits | 1 bit | 1 bit |
			The second downlink is send, no FOpts:
			| LoRaWAN Header | RuleID | W | FCN | 1 tile |
			+ -------------- + ------ + ------ + ------ + -------- +
			| XXXX | 0 | 1 | 0 | 10 bytes |
			The receiver answers with an SCHC ACK
			| RuleID | W = 1 | C = b'1 |
			+ ------ + ----- + ------- +
			| 6 bits | 1 bit | 1 bit |
			The third downlink is send, no FOpts:
			| LoRaWAN Header | RuleID | W | FCN | 1 tile |
			+ -------------- + ------ + ------ + ------ + -------- +
			| XXXX | 0 | 0 | 0 | 10 bytes |
			The receiver answers with an SCHC ACK
			| RuleID | W = 0 | C = 1 |
			+ ------ + ----- + ------- +
			| 6 bits | 1 bit | 1 bit |
			The last downlink is send, no FOpts:
			| LoRaWAN Header | RuleID | W | FCN | 1 tile |
			+ -------------- + ------ + ------ + ------ + -------- +
			| XXXX | 0 | 1 | 1 | 2 bytes |
			The receiver answers with an SCHC ACK
			| RuleID | W = 1 | C = 1 |
			+ ------ + ----- + ------- +
			| 6 bits | 1 bit | 1 bit |
			Figure 18: Downlink example: compression and fragmentation
	Appendix B. Note		Appendix B. Note
	Authors' Addresses		Authors' Addresses
	Olivier Gimenez (editor)		Olivier Gimenez (editor)
	Semtech		Semtech
	14 Chemin des Clos		14 Chemin des Clos
	Meylan		Meylan
	France		France
End of changes. 15 change blocks.
	30 lines changed or deleted		91 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/