< draft-ietf-lpwan-schc-over-lorawan-06.txt		draft-ietf-lpwan-schc-over-lorawan-07.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: October 2, 2020 Acklio		Expires: October 19, 2020 Acklio
	March 31, 2020		April 17, 2020
	Static Context Header Compression (SCHC) over LoRaWAN		Static Context Header Compression (SCHC) over LoRaWAN
	draft-ietf-lpwan-schc-over-lorawan-06		draft-ietf-lpwan-schc-over-lorawan-07
	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 October 2, 2020.		This Internet-Draft will expire on October 19, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 33 ¶		skipping to change at page 2, line 33 ¶
	5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 9		5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 9
	5.3. IID computation . . . . . . . . . . . . . . . . . . . . . 10		5.3. IID computation . . . . . . . . . . . . . . . . . . . . . 10
	5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 11		5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 11
	5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11		5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11
	5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 11		5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.6.2. Uplink fragmentation: From device to SCHC gateway . . 12		5.6.2. Uplink fragmentation: From device to SCHC gateway . . 12
	5.6.3. Downlink fragmentation: From SCHC gateway to a device 15		5.6.3. Downlink fragmentation: From SCHC gateway to a device 15
	6. Security considerations . . . . . . . . . . . . . . . . . . . 18		6. Security considerations . . . . . . . . . . . . . . . . . . . 18
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Normative References . . . . . . . . . . . . . . . . . . 19		9.1. Normative References . . . . . . . . . . . . . . . . . . 19
	9.2. Informative References . . . . . . . . . . . . . . . . . 21		9.2. Informative References . . . . . . . . . . . . . . . . . 20
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21
	A.1. Uplink - Compression example - No fragmentation . . . . . 21		A.1. Uplink - Compression example - No fragmentation . . . . . 21
	A.2. Uplink - Compression and fragmentation example . . . . . 22		A.2. Uplink - Compression and fragmentation example . . . . . 21
	A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 23		A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	The Static Context Header Compression (SCHC) specification		The Static Context Header Compression (SCHC) specification [RFC8724]
	[I-D.ietf-lpwan-ipv6-static-context-hc] describes generic header		describes generic header compression and fragmentation techniques
	compression and fragmentation techniques that can be used on all		that can be used on all LPWAN (Low Power Wide Area Networks)
	LPWAN (Low Power Wide Area Networks) technologies defined in		technologies defined in [RFC8376]. Even though those technologies
	[RFC8376]. Even though those technologies share a great number of		share a great number of common features like star-oriented
	common features like star-oriented topologies, network architecture,		topologies, network architecture, devices with mostly quite
	devices with mostly quite predictable communications, etc; they do		predictable communications, etc; they do have some slight differences
	have some slight differences in respect of payload sizes,		in respect of payload sizes, reactiveness, etc.
	reactiveness, etc.
	SCHC gives a generic framework that enables those devices to		SCHC gives a generic framework that enables those devices to
	communicate with other Internet networks. However, for efficient		communicate with other Internet networks. However, for efficient
	performance, some parameters and modes of operation need to be set		performance, some parameters and modes of operation need to be set
	appropriately for each of the LPWAN technologies.		appropriately for each of the LPWAN technologies.
	This document describes the efficient parameters and modes of		This document describes the efficient parameters and modes of
	operation when SCHC is used over LoRaWAN networks.		operation when SCHC is used over LoRaWAN networks.
	2. Terminology		2. Terminology
	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.
	This section defines the terminology and acronyms used in this		This section defines the terminology and acronyms used in this
	document. For all other definitions, please look up the SCHC		document. For all other definitions, please look up the SCHC
	specification [I-D.ietf-lpwan-ipv6-static-context-hc].		specification [RFC8724].
	o DevEUI: an IEEE EUI-64 identifier used to identify the end-device		o DevEUI: an IEEE EUI-64 identifier used to identify the end-device
	during the procedure while joining the network (Join Procedure)		during the procedure while joining the network (Join Procedure)
	o DevAddr: a 32-bit non-unique identifier assigned to an end-device		o DevAddr: a 32-bit non-unique identifier assigned to an end-device
	statically or dynamically after a Join Procedure (depending on the		statically or dynamically after a Join Procedure (depending on the
	activation mode)		activation mode)
	o RCS: Reassembly Check Sequence. Used to verify the integrity of		o RCS: Reassembly Check Sequence. Used to verify the integrity of
	the fragmentation-reassembly process		the fragmentation-reassembly process
	o TBD: all significant LoRaWAN-related terms.		o TBD: all significant LoRaWAN-related terms.
	o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI		o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI
	3. Static Context Header Compression Overview		3. Static Context Header Compression Overview
	This section contains a short overview of Static Context Header		This section contains a short overview of Static Context Header
	Compression (SCHC). For a detailed description, refer to the full		Compression (SCHC). For a detailed description, refer to the full
	specification [I-D.ietf-lpwan-ipv6-static-context-hc].		specification [RFC8724].
	It defines:		It defines:
	1. Compression mechanisms to avoid transport of known data by both		1. Compression mechanisms to avoid transport of known data by both
	sender and receiver over the air. Known data are part of the		sender and receiver over the air. Known data are part of the
	"context"		"context"
	2. Fragmentation mechanisms to allow SCHC Packet transportation on		2. Fragmentation mechanisms to allow SCHC Packet transportation on
	small, and potentially variable, MTU		small, and potentially variable, MTU
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 26 ¶
	+-------+ |server | |server |		+-------+ |server | |server |
	+-------+ | F/R - C/D |		+-------+ | F/R - C/D |
	+-----------+		+-----------+
	Figure 2: SCHC Architecture mapped to LoRaWAN		Figure 2: SCHC Architecture mapped to LoRaWAN
	4. LoRaWAN Architecture		4. LoRaWAN Architecture
	An overview of LoRaWAN [lora-alliance-spec] protocol and architecture		An overview of LoRaWAN [lora-alliance-spec] protocol and architecture
	is described in [RFC8376]. The mapping between the LPWAN		is described in [RFC8376]. The mapping between the LPWAN
	architecture entities as described in		architecture entities as described in [RFC8724] and the ones in
	[I-D.ietf-lpwan-ipv6-static-context-hc] and the ones in
	[lora-alliance-spec] is as follows:		[lora-alliance-spec] is as follows:
	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 very high density of devices per		actuators, etc.). There can be a very high density of devices per
	radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN		radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN
	End-Device.		End-Device.
	o The Radio Gateway (RGW), which is the endpoint of the constrained		o The Radio Gateway (RGW), which is the endpoint of the constrained
	link. This entity maps to the LoRaWAN Gateway.		link. This entity maps to the LoRaWAN Gateway.
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 12 ¶
	As SCHC defines its own acknowledgment mechanisms, SCHC does not		As SCHC defines its own acknowledgment mechanisms, SCHC does not
	require to use confirmed messages.		require to use confirmed messages.
	4.4. LoRaWAN MAC Frames		4.4. LoRaWAN MAC Frames
	o JoinRequest: This message is used by an end-device to join a		o JoinRequest: This message is used by an end-device to join a
	network. It contains the end-device's unique identifier devEUI		network. It contains the end-device's unique identifier devEUI
	and a random nonce that will be used for session key derivation.		and a random nonce that will be used for session key derivation.
	o JoinAccept: To on-board an end-device, the Network Server responds		o JoinAccept: To on-board an end-device, the Network Server responds
	to the JoinRequest issued by end-device's message with a		to the JoinRequest issued by an end-device with a JoinAccept
	JoinAccept message. That message is encrypted with the end-		message. That message is encrypted with the end-device's AppKey
	device's AppKey and contains (amongst other fields) the major		and contains (amongst other fields) the major network's settings
	network's settings and a network random nonce used to derive the		and a network random nonce used to derive the session keys.
	session keys.
	o Data: MAC and application data. Application data are protected		o Data: MAC and application data. Application data are protected
	with AES-128 encryption, MAC related data are AES-128 encrypted		with AES-128 encryption, MAC related data are AES-128 encrypted
	with another key.		with another key.
	4.5. Unicast and multicast technology		4.5. Unicast and multicast technology
	LoRaWAN technology supports unicast downlinks, but also multicast: a		LoRaWAN technology supports unicast downlinks, but also multicast: a
	packet send over LoRaWAN radio link can be received by several		packet send over LoRaWAN radio link can be received by several
	devices. It is useful to address many end-devices with same content,		devices. It is useful to address many end-devices with same content,
	skipping to change at page 10, line 28 ¶		skipping to change at page 10, line 28 ¶
	In order to mitigate risks described in [RFC8064] and [RFC8065] IID		In order to mitigate risks described in [RFC8064] and [RFC8065] IID
	MUST be created regarding the following algorithm:		MUST be created regarding the following algorithm:
	1. key = LoRaWAN AppSKey		1. key = LoRaWAN AppSKey
	2. cmac = aes128_cmac(key, devEui)		2. cmac = aes128_cmac(key, devEui)
	3. IID = cmac[0..7]		3. IID = cmac[0..7]
	aes128_cmac algorithm is described in [RFC4493]. It has been chosen		aes128_cmac algorithm is described in [RFC4493]. It has been chosen
	as it is already used by devices for LoRaWAN procotol.		as it is already used by devices for LoRaWAN protocol.
	As AppSKey is renewed each time a device joins or rejoins a network,		As AppSKey is renewed each time a device joins or rejoins a network,
	the IID will change over time; this mitigates privacy, location		the IID will change over time; this mitigates privacy, location
	tracking and correlation over time risks. Join periodicity is		tracking and correlation over time risks. Join periodicity is
	defined at the application level.		defined at the application level.
	Address scan risk is mitigated thanks to AES-128, which provides		Address scan risk is mitigated thanks to AES-128, which provides
	enough entropy bits of the IID.		enough entropy bits of the IID.
	Using this algorithm will also ensure that there is no correlation		Using this algorithm will also ensure that there is no correlation
	skipping to change at page 12, line 26 ¶		skipping to change at page 12, line 26 ¶
	o SCHC fragmentation reliability mode: "ACK-on-Error"		o SCHC fragmentation reliability mode: "ACK-on-Error"
	o DTag: Size is 0 bit, not used		o DTag: Size is 0 bit, not used
	o FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63		o FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63
	tiles are allowed in a window		tiles are allowed in a window
	o Window index: encoded on W = 2 bits. So 4 windows are available.		o Window index: encoded on W = 2 bits. So 4 windows are available.
	o RCS: Use recommended calculation algorithm in		o RCS: Use recommended calculation algorithm in [RFC8724].
	[I-D.ietf-lpwan-ipv6-static-context-hc].
	o MAX_ACK_REQUESTS: 8		o MAX_ACK_REQUESTS: 8
	o Tile: size is 10 bytes		o Tile: size is 10 bytes
	o Retransmission timer: LoRaWAN end-devices MUST NOT implement a		o Retransmission timer: LoRaWAN end-devices MUST NOT implement a
	"retransmission timer", this changes the specification of		"retransmission timer", this changes the specification of
	[I-D.ietf-lpwan-ipv6-static-context-hc], see Section 5.6.3.5. It		[RFC8724], see Section 5.6.3.5. It must transmit MAX_ACK_REQUESTS
	must transmit MAX_ACK_REQUESTS time the SCHC ACK REQ at it own		time the SCHC ACK REQ at it own timing; ie the periodicity between
	timing; ie the periodicity between retransmission of SCHC ACK REQs		retransmission of SCHC ACK REQs is device specific and can vary
	is device specific and can vary depending on other application		depending on other application uplinks and regulations.
	uplinks and regulations.
	o Inactivity timer: The SCHC gateway implements an "inactivity		o Inactivity timer: The SCHC gateway implements an "inactivity
	timer". The default RECOMMENDED duration of this timer is 12		timer". The default RECOMMENDED duration of this timer is 12
	hours; this value is mainly driven by application requirements and		hours; this value is mainly driven by application requirements and
	MAY be changed by the application.		MAY be changed by the application.
	o Penultimate tile MUST be equal to the regular size.		o Penultimate tile MUST be equal to the regular size.
	o Last tile: it can be carried in a Regular SCHC Fragment, alone in		o Last tile: it can be carried in a Regular SCHC Fragment, alone in
	an All-1 SCHC Fragment or with any of these two methods:		an All-1 SCHC Fragment or with any of these two methods:
	skipping to change at page 13, line 17 ¶		skipping to change at page 13, line 13 ¶
	SCHC Fragment.		SCHC Fragment.
	* If last tile is in All-1 message: current L2 MTU MUST be big		* If last tile is in All-1 message: current L2 MTU MUST be big
	enough to fit the All-1 and the last tile.		enough to fit the All-1 and the last tile.
	With this set of parameters, the SCHC fragment header is 16 bits,		With this set of parameters, the SCHC fragment header is 16 bits,
	including FPort; payload overhead will be 8 bits as FPort is already		including FPort; payload overhead will be 8 bits as FPort is already
	a part of LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes		a part of LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes
	per tile = 2520 bytes_		per tile = 2520 bytes_
	_Note_: As LoRaWAN is a radio communication, it is RECOMMENDED for an		For battery powered SCHC sender, it is RECOMMENDED to use ACK
	implementation to use ACK mechanism at the end of each window:		mechanism at the end of each window instead of waiting the end of all
			windows:
	o SCHC receiver sends an SCHC ACK after every window even if there		o SCHC receiver SHOULD send a SCHC ACK after every window even if
	is no missing tiles.		there is no missing tiles.
	o SCHC sender waits for the SCHC ACK from the SCHC receiver before		o SCHC sender SHOULD wait for the SCHC ACK from the SCHC receiver
	sending tiles from next window. If the SCHC ACK is not received,		before sending tiles from next window. If the SCHC ACK is not
	it should send an SCHC ACK REQ up to MAX_ACK_REQUESTS time as		received, it SHOULD send an SCHC ACK REQ up to MAX_ACK_REQUESTS
	described previously.		time as described previously.
	This OPTIONAL feature allows the implementation to select between: *		For non-battery powered devices, SCHC receiver MAY also choose to
	SCHC ACK after every window: Save battery life by preventing a device		send a SCHC ACK only at the end of all windows. It will reduce
	to transmit full payload if the network cannot be reached *		downlink load on the network, by reducing the number of downlinks.
	Otherwise: Reduce downlink load on the network by reducing the number
	of downlinks		SCHC implementations MUST be compatible with both behavior, and
			selection is a part of the rule context.
	5.6.2.1. Regular fragments		5.6.2.1. Regular fragments
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + ------------------------- +		+ ------ + ------------------------- +
	| RuleID | W | FCN | Payload |		| RuleID | W | FCN | Payload |
	+ ------ + ------ + ------ + ------- +		+ ------ + ------ + ------ + ------- +
	| 8 bits | 2 bits | 6 bits | |		| 8 bits | 2 bits | 6 bits | |
	Figure 7: All fragments except the last one. SCHC header size is 16		Figure 7: All fragments except the last one. SCHC header size is 16
	skipping to change at page 15, line 22 ¶		skipping to change at page 15, line 22 ¶
	o SCHC fragmentation reliability mode:		o SCHC fragmentation reliability mode:
	* Unicast downlinks: ACK-Always.		* Unicast downlinks: ACK-Always.
	* Multicast downlinks: No-ACK, reliability has to be ensured by		* Multicast downlinks: No-ACK, reliability has to be ensured by
	the upper layer. This feature is OPTIONAL and may not be		the upper layer. This feature is OPTIONAL and may not be
	implemented by SCHC gateway.		implemented by SCHC gateway.
	o RuleID: 8 bits stored in LoRaWAN FPort.		o RuleID: 8 bits stored in LoRaWAN FPort.
	o Window index (unicast only): encoded on W=1 bit, as per		o Window index (unicast only): encoded on W=1 bit, as per [RFC8724].
	[I-D.ietf-lpwan-ipv6-static-context-hc].
	o DTag: Size is 0 bit, not used		o DTag: Size is 0 bit, not used
	o FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile		o FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile
	(FCN=All-1 is reserved for SCHC).		(FCN=All-1 is reserved for SCHC).
	o RCS: Use recommended calculation algorithm in		o RCS: Use recommended calculation algorithm in [RFC8724].
	[I-D.ietf-lpwan-ipv6-static-context-hc].
	o MAX_ACK_REQUESTS: 8		o MAX_ACK_REQUESTS: 8
	As only 1 tile is used, its size can change for each downlink, and		As only 1 tile is used, its size can change for each downlink, and
	will be maximum available MTU.		will be maximum available MTU.
	_Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be		_Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be
	used for SCHC-over-LoRaWAN protocol. It might be set by the Network		used for SCHC-over-LoRaWAN protocol. It might be set by the Network
	Server for other purposes but not SCHC needs.		Server for other purposes but not SCHC needs.
	skipping to change at page 18, line 31 ¶		skipping to change at page 18, line 31 ¶
	receiving, the RECOMMENDED value is 30 seconds. This means that the		receiving, the RECOMMENDED value is 30 seconds. This means that the
	end-device shall try to transmit the ACK within 30 seconds of the		end-device shall try to transmit the ACK within 30 seconds of the
	reception of each fragment. The inactivity timer is implemented by		reception of each fragment. The inactivity timer is implemented by
	the end-device to flush the context in case it receives nothing from		the end-device to flush the context in case it receives nothing from
	the SCHC gateway over an extended period of time. The RECOMMENDED		the SCHC gateway over an extended period of time. The RECOMMENDED
	value is 12 hours for both Class B and Class C end-devices.		value is 12 hours for both Class B and Class C end-devices.
	6. Security considerations		6. Security considerations
	This document is only providing parameters that are expected to be		This document is only providing parameters that are expected to be
	better suited for LoRaWAN networks for		better suited for LoRaWAN networks for [RFC8724]. IID security is
	[I-D.ietf-lpwan-ipv6-static-context-hc]. IID security is discussed		discussed in Section 5.3. As such, this document does not contribute
	in Section 5.3. As such, this document does not contribute to any		to any new security issues in addition to those identified in
	new security issues in addition to those identified in		[RFC8724]. Moreover SCHC data (LoRaWAN payload) are protected on
	[I-D.ietf-lpwan-ipv6-static-context-hc]. Moreover SCHC data (LoRaWAN		LoRaWAN level by an AES-128 encryption with key shared by device and
	payload) are protected on LoRaWAN level by an AES-128 encryption with		SCHC gateway. Those keys are renew each LoRaWAN session (ie: each
	key shared by device and SCHC gateway. Those keys are renew each		join or rejoin to the network)
	LoRaWAN session (ie: each join or rejoin to the network)
	Acknowledgements		Acknowledgements
	Thanks to all those listed in the Contributors section for the		Thanks to all those listed in the Contributors section for the
	excellent text, insightful discussions, reviews and suggestions, and		excellent text, insightful discussions, reviews and suggestions, and
	also to (in alphabetical order) Dominique Barthel, Arunprabhu		also to (in alphabetical order) Dominique Barthel, Arunprabhu
	Kandasamy, Rodrigo Munoz, Alexander Pelov, Pascal Thubert, Laurent		Kandasamy, Rodrigo Munoz, Alexander Pelov, Pascal Thubert, Laurent
	Toutain for useful design considerations, reviews and comments.		Toutain for useful design considerations, reviews and comments.
	Contributors		Contributors
	skipping to change at page 19, line 37 ¶		skipping to change at page 19, line 31 ¶
	Email: nsornin@semtech.com		Email: nsornin@semtech.com
	Alper Yegin		Alper Yegin
	Actility		Actility
	Email: alper.yegin@actility.com		Email: alper.yegin@actility.com
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-lpwan-ipv6-static-context-hc]
	Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
	Zuniga, "Static Context Header Compression (SCHC) and
	fragmentation for LPWAN, application to UDP/IPv6", draft-
	ietf-lpwan-ipv6-static-context-hc-24 (work in progress),
	December 2019.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna,		[RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna,
	"Internet Protocol Small Computer System Interface (iSCSI)		"Internet Protocol Small Computer System Interface (iSCSI)
	Cyclic Redundancy Check (CRC)/Checksum Considerations",		Cyclic Redundancy Check (CRC)/Checksum Considerations",
	RFC 3385, DOI 10.17487/RFC3385, September 2002,		RFC 3385, DOI 10.17487/RFC3385, September 2002,
	<https://www.rfc-editor.org/info/rfc3385>.		<https://www.rfc-editor.org/info/rfc3385>.
	skipping to change at page 21, line 5 ¶		skipping to change at page 20, line 36 ¶
	February 2017, <https://www.rfc-editor.org/info/rfc8065>.		February 2017, <https://www.rfc-editor.org/info/rfc8065>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[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>.
			[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
			Zuniga, "SCHC: Generic Framework for Static Context Header
			Compression and Fragmentation", RFC 8724,
			DOI 10.17487/RFC8724, April 2020,
			<https://www.rfc-editor.org/info/rfc8724>.
	9.2. Informative References		9.2. Informative References
	[lora-alliance-remote-multicast-set]		[lora-alliance-remote-multicast-set]
	Alliance, L., "LoRaWAN Remote Multicast Setup		Alliance, L., "LoRaWAN Remote Multicast Setup
	Specification Version 1.0.0", <https://lora-		Specification Version 1.0.0", <https://lora-
	alliance.org/sites/default/files/2018-09/		alliance.org/sites/default/files/2018-09/
	remote_multicast_setup_v1.0.0.pdf>.		remote_multicast_setup_v1.0.0.pdf>.
	[lora-alliance-spec]		[lora-alliance-spec]
	Alliance, L., "LoRaWAN Specification Version V1.0.3",		Alliance, L., "LoRaWAN Specification Version V1.0.3",
End of changes. 23 change blocks.
	65 lines changed or deleted		58 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/