< draft-petrov-lpwan-ipv6-schc-over-lorawan-02.txt		draft-petrov-lpwan-ipv6-schc-over-lorawan-03.txt >
	lpwan Working Group N. Sornin, Ed.		lpwan Working Group N. Sornin, Ed.
	Internet-Draft M. Coracin		Internet-Draft M. Coracin
	Intended status: Informational Semtech		Intended status: Informational Semtech
	Expires: January 3, 2019 I. Petrov		Expires: August 17, 2019 I. Petrov
	Acklio		Acklio
	A. Yegin		A. Yegin
	Actility		Actility
	J. Catalano		J. Catalano
	Kerlink		Kerlink
	V. Audebert		V. Audebert
	EDF R&D		EDF R&D
	July 02, 2018		February 13, 2019
	Static Context Header Compression (SCHC) over LoRaWAN		Static Context Header Compression (SCHC) over LoRaWAN
	draft-petrov-lpwan-ipv6-schc-over-lorawan-02		draft-petrov-lpwan-ipv6-schc-over-lorawan-03
	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 46 ¶		skipping to change at page 1, line 46 ¶
	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 January 3, 2019.		This Internet-Draft will expire on August 17, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Static Context Header Compression Overview . . . . . . . . . 3		3. Static Context Header Compression Overview . . . . . . . . . 3
	4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 4		4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 4
	4.1. Device classes (A, B, C) and interactions . . . . . . . . 5		4.1. Device classes (A, B, C) and interactions . . . . . . . . 5
	4.2. Device addressing . . . . . . . . . . . . . . . . . . . . 6		4.2. Device addressing . . . . . . . . . . . . . . . . . . . . 6
	4.3. General Message Types . . . . . . . . . . . . . . . . . . 6		4.3. General Message Types . . . . . . . . . . . . . . . . . . 7
	4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 6		4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 7
	5. SCHC over LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 6		5. SCHC over LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Rule ID management . . . . . . . . . . . . . . . . . . . 6		5.1. Rule ID management . . . . . . . . . . . . . . . . . . . 7
	5.2. IID computation . . . . . . . . . . . . . . . . . . . . . 6		5.2. IID computation . . . . . . . . . . . . . . . . . . . . . 8
	5.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 6		5.3. No compression packets are sent using Rule ID 7. . . . . 8
	5.3.1. Reliability options . . . . . . . . . . . . . . . . . 6		5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8
	5.3.2. Supporting multiple window sizes . . . . . . . . . . 11		5.4.1. Uplink fragmentation: From device to gateway . . . . 8
	5.3.3. Downlink fragment transmission . . . . . . . . . . . 11		5.4.2. Downlinks: From gateway to device . . . . . . . . . . 9
	5.3.4. SCHC behavior for devices in class A, B and C . . . . 11		6. Security considerations . . . . . . . . . . . . . . . . . . . 13
	6. Security considerations . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . 11		8.2. Informative References . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . 12		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12		Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 14
	Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	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
	[I-D.ietf-lpwan-overview]. Even though those technologies share a		[I-D.ietf-lpwan-overview]. Even though those technologies share a
	great number of common features like start-oriented topologies,		great number of common features like start-oriented topologies,
	network architecture, devices with mostly quite predictable		network architecture, devices with mostly quite predictable
	communications, etc; they do have some slight differences in respect		communications, etc; they do have some slight differences in respect
	of payload sizes, reactiveness, etc.		of payload sizes, 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",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
	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 [I-D.ietf-lpwan-ipv6-static-context-hc].
	o DevEUI: an IEEE EUI-64 identifier used to identify the device		o DevEUI: an IEEE EUI-64 identifier used to identify the 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 a device		o DevAddr: a 32-bit non-unique identifier assigned to a 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)
	skipping to change at page 5, line 24 ¶		skipping to change at page 5, line 24 ¶
	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. This entity maps to the LoRaWAN		Radio Gateway and the Internet. This entity maps to the LoRaWAN
	Network Server.		Network Server.
	o LPWAN-AAA Server, which controls the user authentication and the		o LPWAN-AAA Server, which controls the user authentication and the
	applications. This entity maps to the LoRaWAN Join Server.		applications. This entity maps to the LoRaWAN Join Server.
	o Application Server (App). The same terminology is used in LoRaWAN.		o Application Server (App). The same terminology is used in LoRaWAN.
	() () () | +------+		() () () | +------+
	() () () () / \ +---------+ | Join |		() () () () / \ +---------+ | Join |
	() () () () () / \======| ^ |===|Server| +-----------+		() () () () () / \======| ^ |===|Server| +-----------+
	() () () | | <--|--> | +------+ |Application|		() () () | | <--|--> | +------+ |Application|
	() () () () / \==========| v |=============| Server |		() () () () / \==========| v |=============| Server |
	() () () / \ +---------+ +-----------+		() () () / \ +---------+ +-----------+
	End-Devices Gateways Network Server		End-Devices Gateways Network Server
	Figure 1: LPWAN/LoRaWAN Architecture		Figure 2: LPWAN Architecture
	SCHC C/D (Compressor/Decompressor) and SCHC Fragmentation are		SCHC C/D (Compressor/Decompressor) and SCHC Fragmentation are
	performed on the LoRaWAN End-device and the Application Server.		performed on the LoRaWAN End-device and the Application Server.
	While the point-to-point link between the End-device and the		While the point-to-point link between the End-device and the
	Application Server constitutes single IP hop, the ultimate end-point		Application Server constitutes single IP hop, the ultimate end-point
	of the IP communication may be an Internet node beyond the		of the IP communication may be an Internet node beyond the
	Application Server. In other words, the LoRaWAN Application Server		Application Server. In other words, the LoRaWAN Application Server
	acts as the first hop IP router for the End-device. Note that the		acts as the first hop IP router for the End-device. Note that the
	Application Server and Network Server may be co-located, which		Application Server and Network Server may be co-located, which
	effectively turns the Network/Application Server into the first hop		effectively turns the Network/Application Server into the first hop
	IP router.		IP router.
	4.1. Device classes (A, B, C) and interactions		4.1. Device classes (A, B, C) and interactions
	TBD		The LoRaWAN MAC layer supports 3 classes of devices named A,B and C.
			All devices implement the classA, some devices implement classA+B or
			class A+C. ClassB and classC are mutually exclusive.
			o *ClassA*: The classA is the simplest class of devices. The device
			is allowed to transmit at any time, randomly selecting a
			communication channel. The network may reply with a downlink in
			one of the 2 receive windows immediately following the uplinks.
			Therefore, the network cannot initiate a downlink, it has to wait
			for the next uplink from the device to get a downlink opportunity.
			The classA is the lowest power device class.
			o *ClassB*: classB devices implement all the functionalities of
			classA devices, but also schedule periodic listen windows.
			Therefore, as opposed the classA devices, classB devices can
			receive downlink that are initiated by the network and not
			following an uplink. There is a trade-off between the periodicity
			of those scheduled classB listen windows and the power consumption
			of the device. The lower the downlink latency, the higher the
			power consumption.
			o *ClassC*: classC devices implement all the functionalities of
			classA devices, but keep their receiver open whenever they are not
			transmitting. ClassC devices can receive downlinks at any time at
			the expense of a higher power consumption. Battery powered
			devices can only operate in classC for a limited amount of time
			(for example for a firmware upgrade over the air). Most of the
			classC devices are main powered (for example Smart Plugs).
	4.2. Device addressing		4.2. Device addressing
	TBD		LoRaWAN devices use a 32bits network address (devAddr) to communicate
			with the network over the air. However that address might be reused
			several time on the same network at the same time for different
			devices. Devices using the same devAddr are distinguish by the
			network server based on the cryptographic signature appended to every
			single LoRaWAN MAC frame, as all devices use different security keys.
			To communicate with the SCHC gateway the network server MUST identify
			the devices by a unique 64bits device ID called the devEUI. Unlike
			devAddr, devEUI is guaranteed to be unique for every single device
			across all networks. The devEUI is assigned to the device during the
			manufacturing process by the device's manufacturer. The devEUI is
			built like an Ethernet MAC address by concatenating the
			manufacturer's IEEE 24bits OUI field with a 40bits serial number.
			The network server translates the devAddr into a devEUI in the uplink
			direction and reciprocally on the downlink direction.
			+--------+ +---------------+ +--------------------+
			| device | <=====> | Network Server| <====> | Application Server |
			+--------+ devAddr +---------------+ devEUI +--------------------+
			Figure 3: LoRaWAN addresses
	4.3. General Message Types		4.3. General Message Types
	TBD		o Confirmed messages:
			o Unconfirmed messages:
	4.4. LoRaWAN MAC Frames		4.4. LoRaWAN MAC Frames
	TBD		o JoinRequest
			o JoinAccept
			o Data
	5. SCHC over LoRaWAN		5. SCHC over LoRaWAN
	5.1. Rule ID management		5.1. Rule ID management
	Rule ID can be stored and transported in the FPort field of the		The LoRaWAN MAC layers features a port field in all frames. This
	LoRaWAN MAC frame or as the first bytes of the payload.		port field (FPort) is 8bit long and the values from 1 to 220 can be
			used. SCHC over LoRaWAN uses 2 contiguous FPort value to separate
			the uplink SCHC traffic from the downlink and avoid any confusion.
			Those FPorts are called FPortUp and FPortDwn. Those FPorts can use
			arbitrary values inside the allowed Fport range but must be shared by
			the end-device and SCHC gateway.
	TBD		SCHC over LoRAWAN SHOULD support encoding RuleID on 3 bits, there are
			therefore 8 possible RuleIds on both uplink and downlink direction.
			The RuleID 0 is reserved for fragmentation in both directions. The 7
			remaining RuleIDs are available for IPV6 header compression. Uplink
			(on FPortUp) and downlink (on FportDwn) RuleIDs are independent. The
			same RuleID may have different meanings on the uplink and downlink
			paths.
			The only uplink messages using the FportDwn port are the
			fragmentation SCHC ACKs messages of a downlink fragmentation session.
			Similarly, the only downlink messages using the FportUp port are the
			fragmentation SCHC ACKs messages of an uplink fragmentation session
	5.2. IID computation		5.2. IID computation
	TBD		TBD (To discuss with the SCHC authors).
	5.3. Fragmentation		5.3. No compression packets are sent using Rule ID 7.
	TBD		5.4. Fragmentation
	5.3.1. Reliability options		The L2 word size used by LoRaWAN is 1 octet (8 bits). The SCHC
			fragmentation over LoRaWAN exclusively uses the ACK-always mode. A
			LoRaWAN device cannot support simultaneous interleaved fragmentation
			sessions in the same direction (uplink or downlink). This means that
			only a single fragmented IPV6 datagram may be transmitted and/or
			received by the device at a given moment. The fragmentation
			parameters are different for uplink and downlink fragmentation
			sessions and are successively described in the next sections.
	5.3.1.1. Uplinks: From device to gateway		5.4.1. Uplink fragmentation: From device to gateway
	In that case the device is the fragmentation transmitter, and the		In that case the device is the fragmentation transmitter, and the
	SCHC gateway the fragmentation receiver.		SCHC gateway the fragmentation receiver.
	o SCHC fragmentation reliability mode : "ACK_ALWAYS"		o SCHC fragmentation reliability mode : "ACK_ALWAYS"
	o Window size: 8, the FCN field is encoded on 3 bits		o Window size: 8, the FCN field is encoded on 3 bits
	o DTag : 1bit. this field is used to clearly separate two		o DTag : 1bit. this field is used to clearly separate two
	consecutive fragmentation sessions. A LoRaWAN device cannot		consecutive fragmentation sessions. A LoRaWAN device cannot
	skipping to change at page 7, line 21 ¶		skipping to change at page 9, line 9 ¶
	between retransmission of the all-0/all-1 fragments is device/		between retransmission of the all-0/all-1 fragments is device/
	application specific and may be different for each device (not		application specific and may be different for each device (not
	specified). The gateway implements an "inactivity timer". The		specified). The gateway implements an "inactivity timer". The
	default recommended duration of this timer is 12h. This value is		default recommended duration of this timer is 12h. This value is
	mainly driven by application requirements and may be changed.		mainly driven by application requirements and may be changed.
	| RuleID | DTag | W | FCN | Payload |		| RuleID | DTag | W | FCN | Payload |
	+ ------ + ----- + ----- | ------ + ------- +		+ ------ + ----- + ----- | ------ + ------- +
	| 3 bits | 1 bit | 1 bit | 3 bits | |		| 3 bits | 1 bit | 1 bit | 3 bits | |
	Figure 2: All fragment except the last one. Header size is 8 bits.		Figure 4: All fragment except the last one. Header size is 8 bits.
	| RuleID | DTag | W | FCN | MIC | Payload |		| RuleID | DTag | W | FCN | MIC | Payload |
	+ ------ + ----- + ----- | ------ + ------- + ------- +		+ ------ + ----- + ----- | ------ + ------- + ------- +
	| 3 bits | 1 bit | 1 bit | 3 bits | 32 bits | |		| 3 bits | 1 bit | 1 bit | 3 bits | 32 bits | |
	Figure 3: All-1 fragment detailed format for the last fragment.		Figure 5: All-1 fragment detailed format for the last fragment.
	Header size is 8 bits.		Header size is 8 bits.
	The format of an all-0 or all-1 acknowledge is:		The format of an all-0 or all-1 acknowledge is:
	| RuleID | DTag | W | Encoded bitmap | Padding (0s) |		| RuleID | DTag | W | Encoded bitmap | Padding (0s) |
	+ ------ + ----- + ----- | -------------- + ------------ +		+ ------ + ----- + ----- | -------------- + ------------ +
	| 3 bits | 1 bit | 1 bit | up to 8 bits | 0 to 3 bits |		| 3 bits | 1 bit | 1 bit | 3 or 8 bits | 0 or 3 bits |
	Figure 4: ACK format for All-0 windows. Header size is 1 or 2 bytes.		Figure 6: ACK format for All-0 windows. Header size is 1 or 2 bytes.
	| RuleID | DTag | W | C | Encoded bitmap (if C = 0) | Padding (0s) |		| RuleID | DTag | W | C | Encoded bitmap (if C = 0) | Padding (0s) |
	+ ------ + ----- + ----- + ----- + ------------------------- + ------------ +		+ ------ + ----- + ----- + ----- + ------------------------- + ------------ +
	| 3 bits | 1 bit | 1 bit | 1 bit | up to 8 bits | 0 to 2 bits |		| 3 bits | 1 bit | 1 bit | 1 bit | 2 or 8 bits | 0 or 2 bits |
	Figure 5: ACK format for All-1 windows. Header size is 1 or 2 bytes.		Figure 7: ACK format for All-1 windows. Header size is 1 or 2 bytes.
	5.3.1.2. Downlinks: From gateway to device		5.4.2. Downlinks: From gateway to device
	In that case the device is the fragmentation receiver, and the SCHC		In that case the device is the fragmentation receiver, and the SCHC
	gateway the fragmentation transmitter. The following fields are		gateway the fragmentation transmitter. The following fields are
	common to all devices.		common to all devices.
	o SCHC fragmentation reliability mode : ACK_ALWAYS		o SCHC fragmentation reliability mode : ACK_ALWAYS
	o Window size : 1 , The FCN field is encoded on 1 bits		o Window size : 1 , The FCN field is encoded on 1 bits
	o DTag : 1bit. This field is used to clearly separate two		o DTag : 1bit. This field is used to clearly separate two
	consecutive fragmentation sessions. A LoRaWAN device cannot		consecutive fragmentation sessions. A LoRaWAN device cannot
	interleave several fragmented SCHC datagrams.		interleave several fragmented SCHC datagrams.
	o MIC calculation algorithm: CRC32 using 0xEDB88320 (i.e. the		o MIC calculation algorithm: CRC32 using 0xEDB88320 (i.e. the
	reverse representation of the polynomial used e.g. in the Ethernet		reverse representation of the polynomial used e.g. in the Ethernet
	standard [RFC3385])		standard [RFC3385])
	o MAX_ACK_REQUESTS : 8		o MAX_ACK_REQUESTS : 8
	| RuleID | DTag | W | FCN | Payload | Padding |		| RuleID | DTag | W | FCN | Payload |
	+ ------ + ----- + ----- | ------ + ------- + ------- +		+ ------ + ----- + ----- | ------ + ------- + ------- +
	| 3 bits | 1 bit | 1 bit | 1 bits | X bytes | 2 bits |		| 3 bits | 1 bit | 1 bit | 1 bits | X bytes + 2 bits |
	Figure 6: All fragments but the last one. Header size is 6 bits.		Figure 8: All fragments but the last one. Header size is 6 bits.
	| RuleID | DTag | W | FCN | MIC | Payload | Padding |		| RuleID | DTag | W | FCN | MIC | Payload | Padding (0s) |
	+ ------ + ----- + ----- | ------ + ------- + ------- + ------- +		+ ------ + ----- + ----- | ------ + ------- + ------- + ------------ +
	| 3 bits | 1 bit | 1 bit | 1 bits | 32 bits | X bytes | 2 bits |		| 3 bits | 1 bit | 1 bit | 1 bits | 32 bits | X bytes | 0 to 7 bits |
	Figure 7: All-1 Fragment Detailed Format for the Last Fragment.		Figure 9: All-1 Fragment Detailed Format for the Last Fragment.
	Header size is 6 bits.		Header size is 6 bits.
	The format of an all-0 or all-1 acknowledge is:		The format of an all-0 or all-1 acknowledge is:
	| RuleID | DTag | W | Encoded bitmap | Padding (0s) |		| RuleID | DTag | W | Encoded bitmap | Padding (0s) |
	+ ------ + ----- + ----- | -------------- + ------------ +		+ ------ + ----- + ----- | -------------- + ------------ +
	| 3 bits | 1 bit | 1 bit | 1 bit | 2 bits |		| 3 bits | 1 bit | 1 bit | 1 bit | 2 bits |
	Figure 8: ACK format for All-0 windows. Header size is 8 bits.		Figure 10: ACK format for All-0 windows. Header size is 8 bits.
	| RuleID | DTag | W | C = 1 | Padding (0s) |		| RuleID | DTag | W | C = 1 | Padding (0s) |
	+ ------ + ----- + ----- + ----- + ------------ +		+ ------ + ----- + ----- + ----- + ------------ +
	| 3 bits | 1 bit | 1 bit | 1 bit | 2 bits |		| 3 bits | 1 bit | 1 bit | 1 bit | 2 bits |
	Figure 9: ACK format for All-1 windows, MIC is correct. Header size		Figure 11: ACK format for All-1 windows, MIC is correct. Header size
	is 8 bits.		is 8 bits.
	| RuleID | DTag | W | b'111 | 0xFF (all 1's) |		| RuleID | DTag | W | b'111 | 0xFF (all 1's) |
	+ ------ + ----- + ----- + ------ + -------------- +		+ ------ + ----- + ----- + ------ + -------------- +
	| 3 bits | 1 bit | 1 bit | 3 bits | 8 bits |		| 3 bits | 1 bit | 1 bit | 3 bits | 8 bits |
	Figure 10: Receiver ABORT packet (following an all-1 packet with		Figure 12: Receiver ABORT packet (following an all-1 packet with
	incorrect MIC). Header size is 16 bits.		incorrect MIC). Header size is 16 bits.
	Class A and classB&C device do not manage retransmissions and timers		Class A and classB&C devices do not manage retransmissions and timers
	in the same way.		in the same way.
	5.3.1.2.1. Class A devices		5.4.2.1. Class A devices
	Class A devices can only receive in an RX slot following the		Class A devices can only receive in an RX slot following the
	transmission of an uplink. Therefore there cannot be a concept of		transmission of an uplink. Therefore there cannot be a concept of
	"retransmission timer" for a gateway talking to classA devices for		"retransmission timer" for a gateway talking to classA devices for
	downlink fragmentation.		downlink fragmentation.
	The device replies with an ACK fragment to every single fragment		The device replies with an ACK fragment to every single fragment
	received from the gateway (because the window size is 1). Following		received from the gateway (because the window size is 1). Following
	the reception of a FCN=0 fragment (fragment that is not the last		the reception of a FCN=0 fragment (fragment that is not the last
	fragment of the packet or ACK-request), the device MUST transmit the		fragment of the packet or ACK-request), the device MUST transmit the
	skipping to change at page 10, line 16 ¶		skipping to change at page 11, line 43 ¶
	datagram) and if the MIC is NOT correct, the device shall transmit a		datagram) and if the MIC is NOT correct, the device shall transmit a
	receiver-ABORT fragment. The device SHALL keep this ABORT message in		receiver-ABORT fragment. The device SHALL keep this ABORT message in
	memory until it receives a downlink from the gateway different from		memory until it receives a downlink from the gateway different from
	an ACK-request indicating that the gateway has received the ABORT		an ACK-request indicating that the gateway has received the ABORT
	message. The fragmentation receiver (device) does not implement		message. The fragmentation receiver (device) does not implement
	retransmission timer and inactivity timer.		retransmission timer and inactivity timer.
	The fragmentation sender (the gateway) implements an inactivity timer		The fragmentation sender (the gateway) implements an inactivity timer
	with default duration 12 hours. Once a fragmentation session is		with default duration 12 hours. Once a fragmentation session is
	started, if the gateway has not received any ACK or receiver-ABORT		started, if the gateway has not received any ACK or receiver-ABORT
	message 12 hours fater the last message from the device was received,		message 12 hours after the last message from the device was received,
	the gateway may flush the fragmentation context. For devices with		the gateway may flush the fragmentation context. For devices with
	very low transmission rates (example 1 packet a day in normal		very low transmission rates (example 1 packet a day in normal
	operation) , that duration may be extended, but this is application		operation) , that duration may be extended, but this is application
	specific.		specific.
	5.3.1.3. Class B or C devices		5.4.2.2. Class B or C devices
	Class B&C devices can receive in scheduled RX slots or in RX slots		Class B&C devices can receive in scheduled RX slots or in RX slots
	following the transmission of an uplink. The device replies with an		following the transmission of an uplink. The device replies with an
	ACK fragment to every single fragment received from the gateway		ACK fragment to every single fragment received from the gateway
	(because the window size is 1). Following the reception of a FCN=0		(because the window size is 1). Following the reception of a FCN=0
	fragment (fragment that is not the last fragment of the packet or		fragment (fragment that is not the last fragment of the packet or
	ACK-request), the device MUST always transmit the corresponding ACK		ACK-request), the device MUST always transmit the corresponding ACK
	fragment even if that fragment has already been received. The ACK		fragment even if that fragment has already been received. The ACK
	bitmap is 1 bit long and is always 1. If the gateway receives this		bitmap is 1 bit long and is always 1. If the gateway receives this
	ACK, it proceeds to send the next window fragment If the		ACK, it proceeds to send the next window fragment If the
	skipping to change at page 11, line 9 ¶		skipping to change at page 12, line 41 ¶
	The device SHALL keep the all-1 ACK message in memory until it		The device SHALL keep the all-1 ACK message in memory until it
	receives a downlink from the gateway different from the last (FCN=1)		receives a downlink from the gateway different from the last (FCN=1)
	fragment indicating that the gateway has received the ACK message.		fragment indicating that the gateway has received the ACK message.
	Following the reception of a FCN=1 fragment (the last fragment of a		Following the reception of a FCN=1 fragment (the last fragment of a
	datagram) and if the MIC is NOT correct, the device shall transmit a		datagram) and if the MIC is NOT correct, the device shall transmit a
	receiver-ABORT fragment. The retransmission timer is used by the		receiver-ABORT fragment. The retransmission timer is used by the
	gateway (the sender), the optimal value is very much application		gateway (the sender), the optimal value is very much application
	specific but here are some recommended default values. For classB		specific but here are some recommended default values. For classB
	devices, this timer trigger is a function of the periodicity of the		devices, this timer trigger is a function of the periodicity of the
	classB ping slots. The recommended value is equal to 3 times the		classB ping slots. The recommended value is equal to 3 times the
	classB ping slot periodicity. (modify 128sec) For classC devices		classB ping slot periodicity. For classC devices which are nearly
	which are nearly constantly receiving, the recommended value is 30		constantly receiving, the recommended value is 30 seconds. This
	seconds. This means that the device shall try to transmit the ACK		means that the device shall try to transmit the ACK within 30 seconds
	within 30 seconds of the reception of each fragment. The inactivity		of the reception of each fragment. The inactivity timer is
	timer is implemented by the device to flush the context in-case it		implemented by the device to flush the context in-case it receives
	receives nothing from the gateway over an extended period of time.		nothing from the gateway over an extended period of time. The
	The recommended value is 12 hours for both classB&C devices.		recommended value is 12 hours for both classB&C devices.
	5.3.2. Supporting multiple window sizes
	TBD
	5.3.3. Downlink fragment transmission
	TBD
	5.3.4. SCHC behavior for devices in class A, B and C
	TBD
	6. Security considerations		6. Security considerations
	TBD		As this document is only providing parameters that are expected to be
			better suited for LoRaWAN networks for
			[I-D.ietf-lpwan-ipv6-static-context-hc]. As such, this parameters
			does not contribute to any new security issues in addition of those
			identified in [I-D.ietf-lpwan-ipv6-static-context-hc].
	7. Acknowledgements		7. Acknowledgements
	TBD		TBD
	8. References		8. References
	8.1. Normative References		8.1. Normative References
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<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>.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4		"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,		Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
	<https://www.rfc-editor.org/info/rfc4944>.		<https://www.rfc-editor.org/info/rfc4944>.
	skipping to change at page 12, line 17 ¶		skipping to change at page 14, line 6 ¶
	DOI 10.17487/RFC5795, March 2010,		DOI 10.17487/RFC5795, March 2010,
	<https://www.rfc-editor.org/info/rfc5795>.		<https://www.rfc-editor.org/info/rfc5795>.
	[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6		[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
	Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,		Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
	February 2014, <https://www.rfc-editor.org/info/rfc7136>.		February 2014, <https://www.rfc-editor.org/info/rfc7136>.
	8.2. Informative References		8.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., and D. Barthel,		Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
	"LPWAN Static Context Header Compression (SCHC) and		Zuniga, "LPWAN Static Context Header Compression (SCHC)
	fragmentation for IPv6 and UDP", draft-ietf-lpwan-ipv6-		and fragmentation for IPv6 and UDP", draft-ietf-lpwan-
	static-context-hc-16 (work in progress), June 2018.		ipv6-static-context-hc-18 (work in progress), December
			2018.
	[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-10 (work in progress), February 2018.		overview-10 (work in progress), February 2018.
	[lora-alliance-spec]		[lora-alliance-spec]
	Alliance, L., "LoRaWAN Specification Version V1.0.2",		Alliance, L., "LoRaWAN Specification Version V1.0.2",
	<http://portal.lora-		<http://portal.lora-
	alliance.org/DesktopModules/Inventures_Document/		alliance.org/DesktopModules/Inventures_Document/
	FileDownload.aspx?ContentID=1398>.		FileDownload.aspx?ContentID=1398>.
End of changes. 44 change blocks.
	89 lines changed or deleted		166 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/