< draft-ietf-lpwan-ipv6-static-context-hc-11.txt		draft-ietf-lpwan-ipv6-static-context-hc-12.txt >
	lpwan Working Group A. Minaburo		lpwan Working Group A. Minaburo
	Internet-Draft Acklio		Internet-Draft Acklio
	Intended status: Informational L. Toutain		Intended status: Informational L. Toutain
	Expires: October 15, 2018 IMT-Atlantique		Expires: November 19, 2018 IMT-Atlantique
	C. Gomez		C. Gomez
	Universitat Politecnica de Catalunya		Universitat Politecnica de Catalunya
	April 13, 2018		May 18, 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-11		draft-ietf-lpwan-ipv6-static-context-hc-12
	Abstract		Abstract
	This document defines the Static Context Header Compression (SCHC)		This document defines the Static Context Header Compression (SCHC)
	framework, which provides header compression and fragmentation		framework, which provides header compression and fragmentation
	functionality. SCHC has been tailored for Low Power Wide Area		functionality. SCHC has been tailored for Low Power Wide Area
	Networks (LPWAN).		Networks (LPWAN).
	SCHC compression is based on a common static context stored in both		SCHC compression is based on a common static context stored in both
	LPWAN devices and in the network sides. This document defines SCHC		LPWAN devices and in the network sides. This document defines SCHC
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 15, 2018.		This Internet-Draft will expire on November 19, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 4		2. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. SCHC overview . . . . . . . . . . . . . . . . . . . . . . . . 8		4. SCHC overview . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Static Context Header Compression . . . . . . . . . . . . . . 12		6. Static Context Header Compression . . . . . . . . . . . . . . 11
	6.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . . 13		6.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . . 12
	6.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . . 15		6.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . . 14
	6.3. Packet processing . . . . . . . . . . . . . . . . . . . . 15		6.3. Packet processing . . . . . . . . . . . . . . . . . . . . 14
	6.4. Matching operators . . . . . . . . . . . . . . . . . . . 17		6.4. Matching operators . . . . . . . . . . . . . . . . . . . 16
	6.5. Compression Decompression Actions (CDA) . . . . . . . . . 17		6.5. Compression Decompression Actions (CDA) . . . . . . . . . 17
	6.5.1. not-sent CDA . . . . . . . . . . . . . . . . . . . . 19		6.5.1. not-sent CDA . . . . . . . . . . . . . . . . . . . . 18
	6.5.2. value-sent CDA . . . . . . . . . . . . . . . . . . . 19		6.5.2. value-sent CDA . . . . . . . . . . . . . . . . . . . 18
	6.5.3. mapping-sent CDA . . . . . . . . . . . . . . . . . . 19		6.5.3. mapping-sent CDA . . . . . . . . . . . . . . . . . . 18
	6.5.4. LSB(y) CDA . . . . . . . . . . . . . . . . . . . . . 19		6.5.4. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 19
	6.5.5. DEViid, APPiid CDA . . . . . . . . . . . . . . . . . 20		6.5.5. DEViid, APPiid CDA . . . . . . . . . . . . . . . . . 19
	6.5.6. Compute-* . . . . . . . . . . . . . . . . . . . . . . 20		6.5.6. Compute-* . . . . . . . . . . . . . . . . . . . . . . 19
	7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 20		7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 20
	7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20		7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
	7.2. Fragmentation Tools . . . . . . . . . . . . . . . . . . . 21		7.2. Fragmentation Tools . . . . . . . . . . . . . . . . . . . 20
	7.3. Reliability modes . . . . . . . . . . . . . . . . . . . . 24		7.3. Reliability modes . . . . . . . . . . . . . . . . . . . . 23
	7.4. Fragmentation Formats . . . . . . . . . . . . . . . . . . 26		7.4. Fragmentation Formats . . . . . . . . . . . . . . . . . . 25
	7.4.1. Fragment format . . . . . . . . . . . . . . . . . . . 26		7.4.1. Fragment format . . . . . . . . . . . . . . . . . . . 25
	7.4.2. All-1 and All-0 formats . . . . . . . . . . . . . . . 27		7.4.2. All-1 and All-0 formats . . . . . . . . . . . . . . . 26
	7.4.3. SCHC ACK format . . . . . . . . . . . . . . . . . . . 28		7.4.3. SCHC ACK format . . . . . . . . . . . . . . . . . . . 28
	7.4.4. Abort formats . . . . . . . . . . . . . . . . . . . . 31		7.4.4. Abort formats . . . . . . . . . . . . . . . . . . . . 30
	7.5. Baseline mechanism . . . . . . . . . . . . . . . . . . . 32		7.5. Baseline mechanism . . . . . . . . . . . . . . . . . . . 31
	7.5.1. No-ACK . . . . . . . . . . . . . . . . . . . . . . . 33		7.5.1. No-ACK . . . . . . . . . . . . . . . . . . . . . . . 33
	7.5.2. ACK-Always . . . . . . . . . . . . . . . . . . . . . 34		7.5.2. ACK-Always . . . . . . . . . . . . . . . . . . . . . 33
	7.5.3. ACK-on-Error . . . . . . . . . . . . . . . . . . . . 36		7.5.3. ACK-on-Error . . . . . . . . . . . . . . . . . . . . 35
	7.6. Supporting multiple window sizes . . . . . . . . . . . . 38		7.6. Supporting multiple window sizes . . . . . . . . . . . . 37
	7.7. Downlink SCHC Fragment transmission . . . . . . . . . . . 38		7.7. Downlink SCHC Fragment transmission . . . . . . . . . . . 37
	8. Padding management . . . . . . . . . . . . . . . . . . . . . 39		8. Padding management . . . . . . . . . . . . . . . . . . . . . 38
	9. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 40		9. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 39
	9.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 40		9.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 39
	9.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 40		9.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 39
	9.3. Flow label field . . . . . . . . . . . . . . . . . . . . 40		9.3. Flow label field . . . . . . . . . . . . . . . . . . . . 40
	9.4. Payload Length field . . . . . . . . . . . . . . . . . . 41		9.4. Payload Length field . . . . . . . . . . . . . . . . . . 40
	9.5. Next Header field . . . . . . . . . . . . . . . . . . . . 41		9.5. Next Header field . . . . . . . . . . . . . . . . . . . . 40
	9.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . . 41		9.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . . 40
	9.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . . 41		9.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . . 41
	9.7.1. IPv6 source and destination prefixes . . . . . . . . 42		9.7.1. IPv6 source and destination prefixes . . . . . . . . 41
	9.7.2. IPv6 source and destination IID . . . . . . . . . . . 42		9.7.2. IPv6 source and destination IID . . . . . . . . . . . 41
	9.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . . 43		9.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . . 42
	9.9. UDP source and destination port . . . . . . . . . . . . . 43		9.9. UDP source and destination port . . . . . . . . . . . . . 42
	9.10. UDP length field . . . . . . . . . . . . . . . . . . . . 43		9.10. UDP length field . . . . . . . . . . . . . . . . . . . . 42
	9.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 43		9.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 43
	10. Security considerations . . . . . . . . . . . . . . . . . . . 44		10. Security considerations . . . . . . . . . . . . . . . . . . . 43
	10.1. Security considerations for header compression . . . . . 44		10.1. Security considerations for header compression . . . . . 43
	10.2. Security considerations for SCHC Fragmentation . . . . . 44		10.2. Security considerations for SCHC
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45		Fragmentation/Reassembly . . . . . . . . . . . . . . . . 43
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 45		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
	12.1. Normative References . . . . . . . . . . . . . . . . . . 45		12.1. Normative References . . . . . . . . . . . . . . . . . . 45
	12.2. Informative References . . . . . . . . . . . . . . . . . 46		12.2. Informative References . . . . . . . . . . . . . . . . . 45
	Appendix A. SCHC Compression Examples . . . . . . . . . . . . . 46		Appendix A. SCHC Compression Examples . . . . . . . . . . . . . 45
	Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 49		Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 48
	Appendix C. Fragmentation State Machines . . . . . . . . . . . . 55		Appendix C. Fragmentation State Machines . . . . . . . . . . . . 54
	Appendix D. SCHC Parameters - Ticket #15 . . . . . . . . . . . . 62		Appendix D. SCHC Parameters - Ticket #15 . . . . . . . . . . . . 61
	Appendix E. Note . . . . . . . . . . . . . . . . . . . . . . . . 63		Appendix E. Note . . . . . . . . . . . . . . . . . . . . . . . . 62
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62
	1. Introduction		1. Introduction
	This document defines a header compression scheme and fragmentation		This document defines a header compression scheme and fragmentation
	functionality, both specially tailored for Low Power Wide Area		functionality, both specially tailored for Low Power Wide Area
	Networks (LPWAN).		Networks (LPWAN).
	Header compression is needed to efficiently bring Internet		Header compression is needed to efficiently bring Internet
	connectivity to the node within an LPWAN network. Some LPWAN		connectivity to the node within an LPWAN network. Some LPWAN
	networks properties can be exploited to get an efficient header		networks properties can be exploited to get an efficient header
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 45 ¶
	o Abort. A SCHC Fragment format to signal the other end-point that		o Abort. A SCHC Fragment format to signal the other end-point that
	the on-going fragment transmission is stopped and finished.		the on-going fragment transmission is stopped and finished.
	o All-0. The SCHC Fragment format for the last frame of a window		o All-0. The SCHC Fragment format for the last frame of a window
	that is not the last one of a packet (see Window in this		that is not the last one of a packet (see Window in this
	glossary).		glossary).
	o All-1. The SCHC Fragment format for the last frame of the packet.		o All-1. The SCHC Fragment format for the last frame of the packet.
	o All-0 empty. An All-0 SCHC Fragment without a payload. It is		o All-0 empty. An All-0 SCHC Fragment without payload. It is used
	used to request the SCHC ACK with the encoded Bitmap when the		to request the SCHC ACK with the encoded Bitmap when the
	Retransmission Timer expires, in a window that is not the last one		Retransmission Timer expires, in a window that is not the last one
	of a packet.		of a packet.
	o All-1 empty. An All-1 SCHC Fragment without a payload. It is		o All-1 empty. An All-1 SCHC Fragment without payload. It is used
	used to request the SCHC ACK with the encoded Bitmap when the		to request the SCHC ACK with the encoded Bitmap when the
	Retransmission Timer expires in the last window of a packet.		Retransmission Timer expires in the last window of a packet.
	o App: LPWAN Application. An application sending/receiving IPv6		o App: LPWAN Application. An application sending/receiving IPv6
	packets to/from the Device.		packets to/from the Device.
	o APP-IID: Application Interface Identifier. Second part of the		o APP-IID: Application Interface Identifier. Second part of the
	IPv6 address that identifies the application server interface.		IPv6 address that identifies the application server interface.
	o Bi: Bidirectional, a rule entry that applies to headers of packets		o Bi: Bidirectional, a rule entry that applies to headers of packets
	travelling in both directions (Up and Dw).		travelling in both directions (Up and Dw).
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 31 ¶
	o C: Checked bit. Used in an acknowledgment (SCHC ACK) header to		o C: Checked bit. Used in an acknowledgment (SCHC ACK) header to
	determine if the MIC locally computed by the receiver matches (1)		determine if the MIC locally computed by the receiver matches (1)
	the received MIC or not (0).		the received MIC or not (0).
	o CDA: Compression/Decompression Action. Describes the reciprocal		o CDA: Compression/Decompression Action. Describes the reciprocal
	pair of actions that are performed at the compressor to compress a		pair of actions that are performed at the compressor to compress a
	header field and at the decompressor to recover the original		header field and at the decompressor to recover the original
	header field value.		header field value.
	o Compress Residue. The bytes that need to be sent after applying		o Compression Residue. The bits that need to be sent after applying
	the SCHC compression over each header field		the SCHC compression over each header field
	o Context: A set of rules used to compress/decompress headers.		o Context: A set of rules used to compress/decompress headers.
	o Dev: Device. A node connected to the LPWAN. A Dev SHOULD		o Dev: Device. A node connected to the LPWAN. A Dev SHOULD
	implement SCHC.		implement SCHC.
	o Dev-IID: Device Interface Identifier. Second part of the IPv6		o Dev-IID: Device Interface Identifier. Second part of the IPv6
	address that identifies the device interface.		address that identifies the device interface.
	o DI: Direction Indicator. This field tells which direction of		o DI: Direction Indicator. This field tells which direction of
	packet travel (Up, Dw or Bi) a rule applies to. This allows for		packet travel (Up, Dw or Bi) a rule applies to. This allows for
	assymmetric processing.		assymmetric processing.
	o DTag: Datagram Tag. This SCHC Fragmentation header field is set to		o DTag: Datagram Tag. This SCHC F/R header field is set to the same
	the same value for all SCHC Fragments carrying the same IPv6		value for all SCHC Fragments carrying the same IPv6 datagram.
	datagram.
	o Dw: Dw: Downlink direction for compression/decompression in both		o Dw: Downlink direction for compression/decompression in both
	sides, from SCHC C/D in the network to SCHC C/D in the Dev.		sides, from SCHC C/D in the network to SCHC C/D in the Dev.
	o FCN: Fragment Compressed Number. This SCHC Fragmentation header		o FCN: Fragment Compressed Number. This SCHC F/R header field
	field carries an efficient representation of a larger-sized		carries an efficient representation of a larger-sized fragment
	fragment number.		number.
	o Field Description. A line in the Rule Table.		o Field Description. A line in the Rule Table.
	o FID: Field Identifier. This is an index to describe the header		o FID: Field Identifier. This is an index to describe the header
	fields in a Rule.		fields in a Rule.
	o FL: Field Length is the length of the field in bits for fixed		o FL: Field Length is the length of the field in bits for fixed
	values or a type (variable, token length, ...) for length unknown		values or a type (variable, token length, ...) for length unknown
	at the rule creation. The length of a header field is defined in		at the rule creation. The length of a header field is defined in
	the specific protocol standard.		the specific protocol standard.
	skipping to change at page 7, line 32 ¶		skipping to change at page 7, line 32 ¶
	o IID: Interface Identifier. See the IPv6 addressing architecture		o IID: Interface Identifier. See the IPv6 addressing architecture
	[RFC7136]		[RFC7136]
	o Inactivity Timer. A timer used after receiving a SCHC Fragment to		o Inactivity Timer. A timer used after receiving a SCHC Fragment to
	detect when there is an error and there is no possibility to		detect when there is an error and there is no possibility to
	continue an on-going SCHC Fragmented packet transmission.		continue an on-going SCHC Fragmented packet transmission.
	o L2: Layer two. The immediate lower layer SCHC interfaces with.		o L2: Layer two. The immediate lower layer SCHC interfaces with.
	It is provided by an underlying LPWAN technology.		It is provided by an underlying LPWAN technology.
	o MIC: Message Integrity Check. A SCHC Fragmentation header field		o MIC: Message Integrity Check. A SCHC F/R header field computed
	computed over an IPv6 packet before fragmentation, used for error		over an IPv6 packet before fragmentation, used for error detection
	detection after IPv6 packet reassembly.		after IPv6 packet reassembly.
	o MO: Matching Operator. An operator used to match a value		o MO: Matching Operator. An operator used to match a value
	contained in a header field with a value contained in a Rule.		contained in a header field with a value contained in a Rule.
	o Retransmission Timer. A timer used by the SCHC Fragment sender		o Retransmission Timer. A timer used by the SCHC Fragment sender
	during an on-going SCHC Fragmented packet transmission to detect		during an on-going SCHC Fragmented packet transmission to detect
	possible link errors when waiting for a possible incoming SCHC		possible link errors when waiting for a possible incoming SCHC
	ACK.		ACK.
	o Rule: A set of header field values.		o Rule: A set of header field values.
	o Rule entry: A column in the rule that describes a parameter of the		o Rule entry: A column in the rule that describes a parameter of the
	header field.		header field.
	o Rule ID: An identifier for a rule, SCHC C/D in both sides share		o Rule ID: An identifier for a rule, SCHC C/D in both sides share
	the same Rule ID for a specific packet. A set of Rule IDs are		the same Rule ID for a specific packet. A set of Rule IDs are
	used to support SCHC Fragmentation functionality.		used to support SCHC F/R functionality.
	o SCHC ACK: A SCHC acknowledgement for fragmentation, this format		o SCHC ACK: A SCHC acknowledgement for fragmentation, this format
	used to report the success or unsuccess reception of a set of SCHC		used to report the success or unsuccess reception of a set of SCHC
	Fragments. See Section 7 for more details.		Fragments. See Section 7 for more details.
	o SCHC C/D: Static Context Header Compression Compressor/		o SCHC C/D: Static Context Header Compression Compressor/
	Decompressor. A mechanism used in both sides, at the Dev and at		Decompressor. A mechanism used in both sides, at the Dev and at
	the network to achieve Compression/Decompression of headers. SCHC		the network to achieve Compression/Decompression of headers. SCHC
	C/D uses SCHC rules to perform compression and decompression.		C/D uses SCHC rules to perform compression and decompression.
			o SCHC F/R: Static Context Header Compression Fragmentation/
			Reassembly. A protocol used in both sides, at the Dev and at the
			network to achieve Fragmentation/Reassembly of fragments. SCHC F/
			R has three reliability modes.
	o SCHC Fragment: A data unit that carries a subset of a SCHC Packet.		o SCHC Fragment: A data unit that carries a subset of a SCHC Packet.
	SCHC Fragmentation is needed when the size of a SCHC packet		SCHC F/R is needed when the size of a SCHC packet exceeds the
	exceeds the available payload size of the underlying L2 technology		available payload size of the underlying L2 technology data unit.
	data unit.see Section 7.		See Section 7.
	o SCHC Packet: A packet (e.g. an IPv6 packet) whose header has been		o SCHC Packet: A packet (e.g. an IPv6 packet) whose header has been
	compressed as per the header compression mechanism defined in this		compressed as per the header compression mechanism defined in this
	document. If the header compression process is unable to actually		document. If the header compression process is unable to actually
	compress the packet header, the packet with the uncompressed		compress the packet header, the packet with the uncompressed
	header is still called a SCHC Packet (in this case, a Rule ID is		header is still called a SCHC Packet (in this case, a Rule ID is
	used to indicate that the packet header has not been compressed).		used to indicate that the packet header has not been compressed).
	See Section 6 for more details.		See Section 6 for more details.
	o TV: Target value. A value contained in the Rule that will be		o TV: Target value. A value contained in the Rule that will be
	skipping to change at page 9, line 26 ¶		skipping to change at page 9, line 26 ¶
	technology		technology
	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 by 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 ------------>|
	| |		| |
	| |
	+--------------------+ +-----------------+		+--------------------+ +-----------------+
	| SCHC Fragmentation | | SCHC Reassembly |		| SCHC Fragmentation | | SCHC Reassembly |
	+--------------------+ +-----------------+		+--------------------+ +-----------------+
	^ | ^ |		^ | ^ |
	| | | |		| | | |
	| | | |
	| | | |
	| | | |
	| | | |
	| +---------- SCHC Fragments ----------+ |		| +---------- SCHC Fragments ----------+ |
	+-------------- SCHC ACK ------------------------+		+-------------- SCHC ACK ------------------------+
	SENDER RECEIVER		SENDER RECEIVER
	*: see {{Frag}} to define the use of Fragmentation and the		*: see Section 7 to define the use of Fragmentation and the
	technology-specific documents for the L2 decision.		technology-specific documents for the L2 decision.
	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
			payload from the original packet (see Figure 4). The Compressed
			Header itself is composed of a Rule ID and a Compression Residue.
			The Compression Residue may be absent, see Section 6. Both the Rule
			ID and the Compression Residue potentially have a variable size, and
			generally are not a mutiple of bytes in size.
	The SCHC Packet Compressed Header is formed by the Rule ID and the		| Rule ID + Compression Residue |
	Compress Residue both have a variable size, and in some cases, the
	Compress Residue is not present depending on the Header Compression
	achievement, see Section 6 for more details. The SCHC Packet has the
	following format:
	| Rule ID + Compress Residue |
	+---------------------------------+--------------------+		+---------------------------------+--------------------+
	| Compressed Header | Payload |		| Compressed Header | Payload |
	+---------------------------------+--------------------+		+---------------------------------+--------------------+
	Figure 4: SCHC Packet		Figure 4: SCHC Packet
	The Fragment Header size is variable and depends on the Fragmentation		The Fragment Header size is variable and depends on the Fragmentation
	parameters. The Fragment payload may contain: Compressed Header or		parameters. The Fragment payload may contain: part of the SCHC
	Payload or both and its size depends on the L2 data unit, see		Packet or Payload or both and its size depends on the L2 data unit,
	Section 7. The SCHC Fragment has the following format:		see Section 7. The SCHC Fragment has the following format:
	| Rule ID + DTAG + W + FCN [+ MIC ] | Comp. Header | Payload |		| Rule ID + DTAG + W + FCN [+ MIC ] | Partial SCHC Packet |
	+-----------------------------------+-------------------------+		+-----------------------------------+-------------------------+
	| Fragment Header | Fragment |		| Fragment Header | Fragment Payload |
	+-----------------------------------+-------------------------+		+-----------------------------------+-------------------------+
	Figure 5: SCHC Fragment		Figure 5: SCHC Fragment
	The SCHC ACK is byte aligned and the ACK Header and the encoded		The SCHC ACK is byte aligned and the ACK Header and the encoded
	Bitmap both have variable size. The SCHC ACK is used only in		Bitmap both have variable size. The SCHC ACK is used only in
	Fragmentation and has the following format:		Fragmentation and has the following format:
	|Rule ID + DTag + W|		|Rule ID + DTag + W|
	+------------------+-------- ... ---------+		+------------------+-------- ... ---------+
	| ACK Header | encoded Bitmap |		| ACK Header | encoded Bitmap |
	+------------------+-------- ... ---------+		+------------------+-------- ... ---------+
	Figure 6: SCHC ACK		Figure 6: SCHC ACK
	5. Rule ID		5. Rule ID
	Rule ID are identifiers used to select either the correct context to		Rule ID are identifiers used to select either the correct context to
	be used for Compression/Decompression functionalities or for SCHC		be used for Compression/Decompression functionalities or for
	Fragmentation or after trying to do SCHC C/D and SCHC Fragmentation		Fragmentation/Reassembly or after trying to do SCHC C/D and SCHC F/R
	the packet is sent as is. The size of the Rule ID is not specified		the packet is sent as is. The size of the Rule ID is not specified
	in this document, as it is implementation-specific and can vary		in this document, as it is implementation-specific and can vary
	according to the LPWAN technology and the number of Rules, among		according to the LPWAN technology and the number of Rules, among
	others.		others.
	The Rule IDs identifiers are used:		The Rule IDs identifiers are used:
	o In the SCHC C/D context to keep the Field Description of the		o In the SCHC C/D context to keep the Field Description of the
	header packet.		header packet.
	o In SCHC Fragmentation to identify the specific modes and settings.		o In SCHC F/R to identify the specific modes and settings. In
	In bidirectional SCHC Fragmentation at least two Rules		bidirectional SCHC F/R at least two Rules
	ID are needed.		ID are needed.
	o To identify the SCHC ACK in fragmentation		o To identify the SCHC ACK in SCHC F/R
	o And at least one Rule ID MAY be reserved to the case where no SCHC		o And at least one Rule ID MAY be reserved to the case where no SCHC
	C/D nor SCHC Fragmentation were possible.		C/D nor SCHC F/R were possible.
	6. Static Context Header Compression		6. Static Context Header Compression
	In order to perform header compression, this document defines a		In order to perform header compression, this document defines a
	mechanism called Static Context Header Compression (SCHC), which is		mechanism called Static Context Header Compression (SCHC), which is
	based on using context, i.e. a set of rules to compress or decompress		based on using context, i.e. a set of rules to compress or decompress
	headers. SCHC avoids context synchronization, which is the most		headers. SCHC avoids context synchronization, which is the most
	bandwidth-consuming operation in other header compression mechanisms		bandwidth-consuming operation in other header compression mechanisms
	such as RoHC [RFC5795]. Since the nature of packets are highly		such as RoHC [RFC5795]. Since the nature of packets are highly
	predictable in LPWAN networks, static contexts MAY be stored		predictable in LPWAN networks, static contexts MAY be stored
	skipping to change at page 12, line 37 ¶		skipping to change at page 12, line 6 ¶
	|SCHC Comp / Frag| | |		|SCHC Comp / Frag| | |
	+--------+-------+ +-------+------+		+--------+-------+ +-------+------+
	| +--+ +----+ +-----------+ .		| +--+ +----+ +-----------+ .
	+~~ |RG| === |NGW | === | SCHC |... Internet ..		+~~ |RG| === |NGW | === | SCHC |... Internet ..
	+--+ +----+ |Comp / Frag|		+--+ +----+ |Comp / Frag|
	+-----------+		+-----------+
	Figure 7: Architecture		Figure 7: Architecture
	Figure 7 The figure represents the architecture for SCHC (Static		Figure 7 The figure represents the architecture for SCHC (Static
	Context Header Compression) Compression / Fragmentation where SCHC C/		Context Header Compression) Compression/Fragmentation where SCHC C/D
	D (Compressor/Decompressor) and SCHC Fragmentation are performed. It		(Compressor/Decompressor) and SCHC F/R (Fragmentation/Reassembly) are
	is based on [I-D.ietf-lpwan-overview] terminology. SCHC Compression		performed. It is based on {{I-D.ietf- lpwan-overview}} terminology.
	/ Fragmentation is located on both sides of the transmission in the		SCHC Compression/Fragmentation is located on both sides of the
	Dev and in the Network side. In the Uplink direction, the Device		transmission in the Dev and in the Network side. In the Uplink
	application packets use IPv6 or IPv6/UDP protocols. Before sending		direction, the Device application packets use IPv6 or IPv6/UDP
	these packets, the Dev compresses their headers using SCHC C/D and if		protocols. Before sending these packets, the Dev compresses their
	the SCHC Packet resulting from the compression exceeds the maximum		headers using SCHC C/D and if the SCHC Packet resulting from the
	payload size of the underlying LPWAN technology, SCHC Fragmentation		compression exceeds the maximum payload size of the underlying LPWAN
	is performed, see Section 7. The resulting SCHC Fragments are sent		technology, SCHC F/R is performed, see Section 7. The resulting SCHC
	as one or more L2 frames to an LPWAN Radio Gateway (RG) which		Fragments are sent as one or more L2 frames to an LPWAN Radio Gateway
	forwards the frame(s) to a Network Gateway (NGW).		(RG) which forwards the frame(s) to a Network Gateway (NGW).
	The NGW sends the data to an SCHC Fragmentation and then to the SCHC		The NGW sends the data to a SCHC F/R and then to the SCHC C/D for
	C/D for decompression. The SCHC C/D in the Network side can be		decompression. The SCHC C/D in the Network side can be located in
	located in the Network Gateway (NGW) or somewhere else as long as a		the Network Gateway (NGW) or somewhere else as long as a tunnel is
	tunnel is established between the NGW and the SCHC Compression /		established between the NGW and the SCHC Compression/Fragmentation.
	Fragmentation. Note that, for some LPWAN technologies, it MAY be		Note that, for some LPWAN technologies, it MAY be suitable to locate
	suitable to locate SCHC Fragmentation and reassembly functionality		SCHC Fragmentation/Reassembly functionality nearer the NGW, in order
	nearer the NGW, in order to better deal with time constraints of such		to better deal with time constraints of such technologies. The SCHC
	technologies. The SCHC C/Ds on both sides MUST share the same set of		C/Ds on both sides MUST share the same set of Rules. After
	Rules. After decompression, the packet can be sent over the Internet		decompression, the packet can be sent over the Internet to one or
	to one or several LPWAN Application Servers (App).		several LPWAN Application Servers (App).
	The SCHC Compression / Fragmentation process is symmetrical,		The SCHC Compression/Fragmentation process is symmetrical, therefore
	therefore the same description applies to the reverse direction.		the same description applies to the reverse direction.
	6.1. SCHC C/D Rules		6.1. SCHC C/D Rules
	The main idea of the SCHC compression scheme is to transmit the Rule		The main idea of the SCHC compression scheme is to transmit the Rule
	ID to the other end instead of sending known field values. This Rule		ID to the other end instead of sending known field values. This Rule
	ID identifies a rule that provides the closest match to the original		ID identifies a rule that provides the closest match to the original
	packet values. Hence, when a value is known by both ends, it is only		packet values. Hence, when a value is known by both ends, it is only
	necessary to send the corresponding Rule ID over the LPWAN network.		necessary to send the corresponding Rule ID over the LPWAN network.
	How Rules are generated is out of the scope of this document. The		How Rules are generated is out of the scope of this document. The
	rule MAY be changed but it will be specified in another document.		rule MAY be changed but it will be specified in another document.
	skipping to change at page 16, line 11 ¶		skipping to change at page 15, line 31 ¶
	* Once the DI and the FP correspond to the header information,		* Once the DI and the FP correspond to the header information,
	each field's value of the packet is then compared to the		each field's value of the packet is then compared to the
	corresponding Target Value (TV) stored in the Rule for that		corresponding Target Value (TV) stored in the Rule for that
	specific field using the matching operator (MO).		specific field using the matching operator (MO).
	If all the fields in the packet's header satisfy all the		If all the fields in the packet's header satisfy all the
	matching operators (MO) of a Rule (i.e. all MO results are		matching operators (MO) of a Rule (i.e. all MO results are
	True), the fields of the header are then compressed according		True), the fields of the header are then compressed according
	to the Compression/Decompression Actions (CDAs) and a		to the Compression/Decompression Actions (CDAs) and a
	compressed header (with possibly a Compressed Residue) SHOULD		compressed header (with possibly a Compression Residue) SHOULD
	be obtained. Otherwise, the next Rule is tested.		be obtained. Otherwise, the next Rule is tested.
	* If no eligible Rule is found, then the header MUST be sent		* If no eligible Rule is found, then the header MUST be sent
	without compression, depending on the L2 PDU size, this is one		without compression, depending on the L2 PDU size, this is one
	of the case that MAY require the use of the SCHC Fragmentation		of the case that MAY require the use of the SCHC F/R process.
	process.
	o Sending: If an eligible Rule is found, the Rule ID is sent to the		o Sending: If an eligible Rule is found, the Rule ID is sent to the
	other end followed by the Compression Residue (which could be		other end followed by the Compression Residue (which could be
	empty) and directly followed by the payload. The product of the		empty) and directly followed by the payload. The Compression
	Compression Residue is sent in the order expressed in the Rule for		Residue is the concatenation of the Compression Residues for each
	all the fields. The way the Rule ID is sent depends on the		field according to the CDAs for that rule. The way the Rule ID is
	specific LPWAN layer two technology. For example, it can be		sent depends on the specific LPWAN layer two technology. For
	either included in a Layer 2 header or sent in the first byte of		example, it can be either included in a Layer 2 header or sent in
	the L2 payload. (Cf. Figure 9). This process will be specified		the first byte of the L2 payload. (Cf. Figure 9). This process
	in the LPWAN technology-specific document and is out of the scope		will be specified in the LPWAN technology-specific document and is
	of the present document. On LPWAN technologies that are byte-		out of the scope of the present document. On LPWAN technologies
	oriented, the compressed header concatenated with the original		that are byte- oriented, the compressed header concatenated with
	packet payload is padded to a multiple of 8 bits, if needed. See		the original packet payload is padded to a multiple of 8 bits, if
	Section 8 for details.		needed. See Section 8 for details.
	o Decompression: When doing decompression, in the network side the		o Decompression: When doing decompression, in the network side the
	SCHC C/D needs to find the correct Rule based on the L2 address		SCHC C/D needs to find the correct Rule based on the L2 address
	and in this way, it can use the Dev-ID and the Rule-ID. In the		and in this way, it can use the Dev-ID and the Rule-ID. In the
	Dev side, only the Rule ID is needed to identify the correct Rule		Dev side, only the Rule ID is needed to identify the correct Rule
	since the Dev only holds Rules that apply to itself.		since the Dev only holds Rules that apply to itself.
	The receiver identifies the sender through its device-id (e.g.		The receiver identifies the sender through its device-id (e.g.
	MAC address, if exists) and selects the appropriate Rule		MAC address, if exists) and selects the appropriate Rule
	from the Rule ID. If a source identifier is present in the L2		from the Rule ID. If a source identifier is present in the L2
	skipping to change at page 18, line 12 ¶		skipping to change at page 17, line 20 ¶
	taken during the compression of headers fields, and inversely, the		taken during the compression of headers fields, and inversely, the
	action taken by the decompressor to restore the original value.		action taken by the decompressor to restore the original value.
	/--------------------+-------------+----------------------------\		/--------------------+-------------+----------------------------\
	| Action | Compression | Decompression |		| Action | Compression | Decompression |
	| | | |		| | | |
	+--------------------+-------------+----------------------------+		+--------------------+-------------+----------------------------+
	|not-sent |elided |use value stored in ctxt |		|not-sent |elided |use value stored in ctxt |
	|value-sent |send |build from received value |		|value-sent |send |build from received value |
	|mapping-sent |send index |value from index on a table |		|mapping-sent |send index |value from index on a table |
	|LSB(y) |send LSB |TV, received value |		|LSB |send LSB |TV, received value |
	|compute-length |elided |compute length |		|compute-length |elided |compute length |
	|compute-checksum |elided |compute UDP checksum |		|compute-checksum |elided |compute UDP checksum |
	|Deviid |elided |build IID from L2 Dev addr |		|Deviid |elided |build IID from L2 Dev addr |
	|Appiid |elided |build IID from L2 App addr |		|Appiid |elided |build IID from L2 App addr |
	\--------------------+-------------+----------------------------/		\--------------------+-------------+----------------------------/
	y=size of the transmitted bits		y=size of the transmitted bits
	Figure 10: Compression and Decompression Functions		Figure 10: Compression and Decompression Functions
	Figure 10 summarizes the basic functions that can be used to compress		Figure 10 summarizes the basic functions that can be used to compress
	skipping to change at page 19, line 13 ¶		skipping to change at page 18, line 19 ¶
	is variable, the size zero MUST be used.		is variable, the size zero MUST be used.
	6.5.1. not-sent CDA		6.5.1. not-sent CDA
	The not-sent function is generally used when the field value is		The not-sent function is generally used when the field value is
	specified in the Rule and therefore known by both the Compressor and		specified in the Rule and therefore known by both the Compressor and
	the Decompressor. This action is generally used with the "equal" MO.		the Decompressor. This action is generally used with the "equal" MO.
	If MO is "ignore", there is a risk to have a decompressed field value		If MO is "ignore", there is a risk to have a decompressed field value
	different from the compressed field.		different from the compressed field.
	The compressor does not send any value in the Compressed Residue for		The compressor does not send any Compression Residue for a field on
	a field on which not-sent compression is applied.		which not-sent compression is applied.
	The decompressor restores the field value with the Target Value		The decompressor restores the field value with the Target Value
	stored in the matched Rule identified by the received Rule ID.		stored in the matched Rule identified by the received Rule ID.
	6.5.2. value-sent CDA		6.5.2. value-sent CDA
	The value-sent action is generally used when the field value is not		The value-sent action is generally used when the field value is not
	known by both Compressor and Decompressor. The value is sent in the		known by both Compressor and Decompressor. The value is sent in the
	compressed message header. Both Compressor and Decompressor MUST		compressed message header. Both Compressor and Decompressor MUST
	know the size of the field, either implicitly (the size is known by		know the size of the field, either implicitly (the size is known by
	both sides) or explicitly in the compression residue by indicating		both sides) or by explicitly indicating the length in the Compression
	the length, as defined in Section 6.5. This function is generally		Residue, as defined in Section 6.5. This function is generally used
	used with the "ignore" MO.		with the "ignore" MO.
	6.5.3. mapping-sent CDA		6.5.3. mapping-sent CDA
	The mapping-sent is used to send a smaller index (the index into the		The mapping-sent is used to send a smaller index (the index into the
	Target Value list of values) instead of the original value. This		Target Value list of values) instead of the original value. This
	function is used together with the "match-mapping" MO.		function is used together with the "match-mapping" MO.
	On the compressor side, the match-mapping Matching Operator searches		On the compressor side, the match-mapping Matching Operator searches
	the TV for a match with the header field value and the mapping-sent		the TV for a match with the header field value and the mapping-sent
	CDA appends the corresponding index to the Compression Residue to be		CDA appends the corresponding index to the Compression Residue to be
	sent. On the decompressor side, the CDA uses the received index to		sent. On the decompressor side, the CDA uses the received index to
	restore the field value by looking up the list in the TV.		restore the field value by looking up the list in the TV.
	The number of bits sent is the minimal size for coding all the		The number of bits sent is the minimal size for coding all the
	possible indices.		possible indices.
	6.5.4. LSB(y) CDA		6.5.4. LSB CDA
	The LSB(y) action is used together with the "MSB(x)" MO to avoid		The LSB action is used together with the "MSB(x)" MO to avoid sending
	sending the higher part of the packet field if that part is already		the higher part of the packet field if that part is already known by
	known by the receiving end. A length can be specified in the rule to		the receiving end. A length can be specified in the rule to indicate
	indicate how many bits have to be sent. If the length is not		how many bits have to be sent. If the length is not specified, the
	specified, the number of bits sent is the original header field		number of bits sent is the original header field length minus the
	length minus the length specified in the MSB(x) MO.		length specified in the MSB(x) MO.
	The compressor sends the Least Significant Bits (e.g. LSB of the		The compressor sends the Least Significant Bits (e.g. LSB of the
	length field). The decompressor combines the value received with the		length field). The decompressor combines the value received with the
	Target Value depending on the field type.		Target Value depending on the field type.
	If this action needs to be done on a variable length field, the size		If this action needs to be done on a variable length field, the size
	of the Compressed Residue in bytes MUST be sent as described in		of the Compression Residue in bytes MUST be sent as described in
	Section 6.5.		Section 6.5.
	6.5.5. DEViid, APPiid CDA		6.5.5. DEViid, APPiid CDA
	These functions are used to process respectively the Dev and the App		These functions are used to process respectively the Dev and the App
	Interface Identifiers (Deviid and Appiid) of the IPv6 addresses.		Interface Identifiers (Deviid and Appiid) of the IPv6 addresses.
	Appiid CDA is less common since current LPWAN technologies frames		Appiid CDA is less common since current LPWAN technologies frames
	contain a single address, which is the Dev's address.		contain a single address, which is the Dev's address.
	The IID value MAY be computed from the Device ID present in the Layer		The IID value MAY be computed from the Device ID present in the Layer
	skipping to change at page 20, line 45 ¶		skipping to change at page 20, line 10 ¶
	o compute-checksum: computes a checksum from the information already		o compute-checksum: computes a checksum from the information already
	received by the SCHC C/D. This field MAY be used to compute UDP		received by the SCHC C/D. This field MAY be used to compute UDP
	checksum.		checksum.
	7. Fragmentation		7. Fragmentation
	7.1. Overview		7.1. Overview
	In LPWAN technologies, the L2 data unit size typically varies from		In LPWAN technologies, the L2 data unit size typically varies from
	tens to hundreds of bytes. The SCHC Fragmentation MAY be used either		tens to hundreds of bytes. The SCHC Fragmentation /Reassembly MAY be
	because after applying SCHC C/D or when SCHC C/D is not possible the		used either because after applying SCHC C/D or when SCHC C/D is not
	entire SCHC Packet still exceeds the L2 data unit.		possible the entire SCHC Packet still exceeds the L2 data unit.
	The SCHC Fragmentation functionality defined in this document has		The SCHC F/R functionality defined in this document has been designed
	been designed under the assumption that data unit out-of- sequence		under the assumption that data unit out-of- sequence delivery will
	delivery will not happen between the entity performing fragmentation		not happen between the entity performing fragmentation and the entity
	and the entity performing reassembly. This assumption allows		performing reassembly. This assumption allows reducing the
	reducing the complexity and overhead of the SCHC Fragmentation		complexity and overhead of the SCHC F/R mechanism.
	mechanism.
	To adapt the SCHC Fragmentation to the capabilities of LPWAN		To adapt the SCHC F/R to the capabilities of LPWAN technologies is
	technologies is required to enable optional SCHC Fragment		required to enable optional SCHC Fragment retransmission and to allow
	retransmission and to allow a stepper delivery for the reliability of		a stepper delivery for the reliability of SCHC Fragments. This
	SCHC Fragments. This document does not make any decision with regard		document does not make any decision with regard to which SCHC
	to which SCHC Fragment delivery reliability mode will be used over a		Fragment delivery reliability mode will be used over a specific LPWAN
	specific LPWAN technology. These details will be defined in other		technology. These details will be defined in other technology-
	technology-specific documents.		specific documents.
	7.2. Fragmentation Tools		7.2. Fragmentation Tools
	This subsection describes the different tools that are used to enable		This subsection describes the different tools that are used to enable
	the SCHC Fragmentation functionality defined in this document, such		the SCHC F/R functionality defined in this document, such as fields
	as fields in the SCHC Fragmentation header frames (see the related		in the SCHC F/R header frames (see the related formats in
	formats in Section 7.4), and the different parameters supported in		Section 7.4), and the different parameters supported in the
	the reliability modes such as timers and parameters.		reliability modes such as timers and parameters.
	o Rule ID. The Rule ID is present in the SCHC Fragment header and		o Rule ID. The Rule ID is present in the SCHC Fragment header and
	in the SCHC ACK header format. The Rule ID in a SCHC fragment		in the SCHC ACK header format. The Rule ID in a SCHC fragment
	header is used to identify that a SCHC Fragment is being carried,		header is used to identify that a SCHC Fragment is being carried,
	which SCHC Fragmentation reliability mode is used and which window		which SCHC F/R reliability mode is used and which window size is
	size is used. The Rule ID in the SCHC Fragmentation header also		used. The Rule ID in the SCHC F/R header also allows interleaving
	allows interleaving non-fragmented		non-fragmented
	packets and SCHC Fragments that carry other SCHC Packets. The		packets and SCHC Fragments that carry other SCHC Packets. The
	Rule ID in an SCHC ACK identifies the message as an SCHC ACK.		Rule ID in an SCHC ACK identifies the message as an SCHC ACK.
	o Fragment Compressed Number (FCN). The FCN is included in all SCHC		o Fragment Compressed Number (FCN). The FCN is included in all SCHC
	Fragments. This field can be understood as a truncated,		Fragments. This field can be understood as a truncated,
	efficient representation of a larger-sized fragment number, and		efficient representation of a larger-sized fragment number, and
	does not carry an absolute SCHC Fragment number. There are two		does not carry an absolute SCHC Fragment number. There are two
	FCN reserved values that are used for controlling the SCHC		FCN reserved values that are used for controlling the SCHC F/R
	Fragmentation process, as described next:		process, as described next:
	* The FCN value with all the bits equal to 1 (All-1) denotes the		* The FCN value with all the bits equal to 1 (All-1) denotes the
	last SCHC Fragment of a packet. The last window of a packet is		last SCHC Fragment of a packet. The last window of a packet is
	called an All-1 window.		called an All-1 window.
	* The FCN value with all the bits equal to 0 (All-0) denotes the		* The FCN value with all the bits equal to 0 (All-0) denotes the
	last SCHC Fragment of a window that is not the last one of the		last SCHC Fragment of a window that is not the last one of the
	packet. Such a window is called an All-0 window.		packet. Such a window is called an All-0 window.
	The rest of the FCN values are assigned in a sequentially		The rest of the FCN values are assigned in a sequentially
	skipping to change at page 25, line 11 ¶		skipping to change at page 24, line 22 ¶
	before the end of the SCHC Packet transmission as long as the		before the end of the SCHC Packet transmission as long as the
	window size is short enough. However, such benefit comes at the		window size is short enough. However, such benefit comes at the
	expense of SCHC ACK use. In ACK-Always the receiver sends an SCHC		expense of SCHC ACK use. In ACK-Always the receiver sends an SCHC
	ACK after a window of SCHC Fragments has been received, where a		ACK after a window of SCHC Fragments has been received, where a
	window of SCHC Fragments is a subset of the whole number of SCHC		window of SCHC Fragments is a subset of the whole number of SCHC
	Fragments needed to carry a complete SCHC Packet. The SCHC ACK is		Fragments needed to carry a complete SCHC Packet. The SCHC ACK is
	used to inform the sender if a SCHC fragment in the actual window		used to inform the sender if a SCHC fragment in the actual window
	has been lost or well received. Upon an SCHC ACK reception, the		has been lost or well received. Upon an SCHC ACK reception, the
	sender retransmits the lost SCHC Fragments. When an SCHC ACK is		sender retransmits the lost SCHC Fragments. When an SCHC ACK is
	lost and the sender has not received it before the expiration of		lost and the sender has not received it before the expiration of
	the Inactivity Timer, the sender uses an SCHC ACK request by		the Retransmission Timer, the sender uses an SCHC ACK request by
	sending the All-1 empty SCHC Fragment. The maximum number of SCHC		sending the All-0 empty SCHC Fragment when it is not the last
	ACK requests is MAX_ACK_REQUESTS. If the MAX_ACK_REQUEST is		windown and the ALL-1 empty Fragment when it is the last window.
	reached the transmission needs to be Aborted. See further details		The maximum number of SCHC ACK requests is MAX_ACK_REQUESTS. If
	in {{ACK- Always-subsection}}.		the MAX_ACK_REQUEST is reached the transmission needs to be
			Aborted. See further details in Section 7.5.2.
	o ACK-on-Error. The ACK-on-Error mode is suitable for links		o ACK-on-Error. The ACK-on-Error mode is suitable for links
	offering relatively low L2 data unit loss probability. In this		offering relatively low L2 data unit loss probability. In this
	mode, the SCHC Fragment receiver reduces the number of SCHC ACKs		mode, the SCHC Fragment receiver reduces the number of SCHC ACKs
	transmitted, which MAY be especially beneficial in asymmetric		transmitted, which MAY be especially beneficial in asymmetric
	scenarios. Because the SCHC Fragments use the uplink of the		scenarios. Because the SCHC Fragments use the uplink of the
	underlying LPWAN technology, which has higher capacity than		underlying LPWAN technology, which has higher capacity than
	downlink. The receiver transmits an SCHC ACK only after the		downlink. The receiver transmits an SCHC ACK only after the
	complete window transmission and if at least one SCHC Fragment of		complete window transmission and if at least one SCHC Fragment of
	this window has been lost. An exception to this behavior is in		this window has been lost. An exception to this behavior is in
	skipping to change at page 26, line 42 ¶		skipping to change at page 26, line 12 ¶
	SHALL conform the detailed format defined in Figure 12. The total		SHALL conform the detailed format defined in Figure 12. The total
	size of the fragment header is not byte aligned.		size of the fragment header is not byte aligned.
	|---Fragmentation Header----|		|---Fragmentation Header----|
	|-- T --|1|-- N --|		|-- T --|1|-- N --|
	+-- ... --+- ... -+-+- ... -+--------...-------+		+-- ... --+- ... -+-+- ... -+--------...-------+
	| Rule ID | DTag |W| FCN | Fragment payload |		| Rule ID | DTag |W| FCN | Fragment payload |
	+-- ... --+- ... -+-+- ... -+--------...-------+		+-- ... --+- ... -+-+- ... -+--------...-------+
	Figure 12: Fragment Detailed Format for Fragments except the Last		Figure 12: Fragment Detailed Format for Fragments except the Last
	One, Window mode		One, ACK-Always and ACK-on-Error
	In the No-ACK mode, SCHC Fragments except the last one SHALL conform		In the No-ACK mode, SCHC Fragments except the last one SHALL conform
	to the detailed format defined in Figure 13. The total size of the		to the detailed format defined in Figure 13. The total size of the
	fragment header is not byte aligned.		fragment header is not byte aligned.
	|---Fragmentation Header---|		|---Fragmentation Header---|
	|-- T --|-- N --|		|-- T --|-- N --|
	+-- ... --+- ... -+- ... -+--------...-------+		+-- ... --+- ... -+- ... -+--------...-------+
	| Rule ID | DTag | FCN | Fragment payload |		| Rule ID | DTag | FCN | Fragment payload |
	+-- ... --+- ... -+- ... -+--------...-------+		+-- ... --+- ... -+- ... -+--------...-------+
	skipping to change at page 31, line 9 ¶		skipping to change at page 30, line 25 ¶
	+---------+------+-+-+-+-+-+-+-+-----+~~		+---------+------+-+-+-+-+-+-+-+-----+~~
	|<-- byte boundary ->|<---- 1 byte---->|		|<-- byte boundary ->|<---- 1 byte---->|
	Figure 23: Example of a Bitmap before transmission, and the		Figure 23: Example of a Bitmap before transmission, and the
	transmitted one, in any window except the last one		transmitted one, in any window except the last one
	Figure 24 shows an example of an SCHC ACK with FCN ranging from 6		Figure 24 shows an example of an SCHC ACK with FCN ranging from 6
	down to 0, where the Bitmap indicates that the MIC check has failed		down to 0, where the Bitmap indicates that the MIC check has failed
	but there are no missing SCHC Fragments.		but there are no missing SCHC Fragments.
	<------- R -------> 6 5 4 3 2 1 7 (*)		|-Fragmentation Header-|6 5 4 3 2 1 7 (*)
	|-- T --|1|		|-- T --|1|
	| Rule ID | DTag |W|0|1|1|1|1|1|1|1|padding| Bitmap (before tx)		| Rule ID | DTag |W|0|1|1|1|1|1|1|1|padding| Bitmap (before tx)
	|---- byte boundary -----| 1 byte next |		|---- byte boundary -----| 1 byte next |
	C		C
	+---- ... --+-... -+-+-+-+		+---- ... --+-... -+-+-+-+
	| Rule ID | DTag |W|0|1| encoded Bitmap		| Rule ID | DTag |W|0|1| encoded Bitmap
	+---- ... --+-... -+-+-+-+		+---- ... --+-... -+-+-+-+
	|---- byte boundary -----|		|---- byte boundary -----|
	(*) = (FCN values indicating the order)		(*) = (FCN values indicating the order)
	skipping to change at page 36, line 25 ¶		skipping to change at page 35, line 41 ¶
	The senders behavior for ACK-on-Error and ACK-Always are similar.		The senders behavior for ACK-on-Error and ACK-Always are similar.
	The main difference is that in ACK-on-Error the SCHC ACK with the		The main difference is that in ACK-on-Error the SCHC ACK with the
	encoded Bitmap is not sent at the end of each window but only when at		encoded Bitmap is not sent at the end of each window but only when at
	least one SCHC Fragment of the current window has been lost. Excepts		least one SCHC Fragment of the current window has been lost. Excepts
	for the last window where an SCHC ACK MUST be sent to finish the		for the last window where an SCHC ACK MUST be sent to finish the
	transmission.		transmission.
	In ACK-on-Error, the Retransmission Timer expiration will be		In ACK-on-Error, the Retransmission Timer expiration will be
	considered as a positive acknowledgment. This timer is set after		considered as a positive acknowledgment. This timer is set after
	sending an All-0 or an All-1 fragment. When the All-1 fragment has		sending an All-0 or an All-1 fragment. When the All-1 fragment has
	been sent, then the on-going SCHC Fragmentation process is finished		been sent, then the on-going SCHC F/R process is finished and the
	and the sender waits for the last SCHC ACK. If the Retransmission		sender waits for the last SCHC ACK. If the Retransmission Timer
	Timer expires while waiting for the SCHC ACK for the last window, an		expires while waiting for the SCHC ACK for the last window, an All-1
	All-1 empty MUST be sent to request the last SCHC ACK by the sender		empty MUST be sent to request the last SCHC ACK by the sender to
	to complete the SCHC Fragmented packet transmission. When it expires		complete the SCHC Fragmented packet transmission. When it expires
	the sender continue sending SCHC Fragments of the next window.		the sender continue sending SCHC Fragments of the next window.
	If the sender receives an SCHC ACK, it checks the window value. SCHC		If the sender receives an 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 on the received encoded Bitmap is correct, the sender verifies
	if the receiver has received all SCHC fragments of the current		if the receiver has received all SCHC fragments of the current
	window. When at least one SCHC Fragment has been lost, the counter		window. When at least one SCHC Fragment has been lost, the counter
	Attempts is increased by one and the sender resends the missing SCHC		Attempts is increased by one and the sender resends the missing SCHC
	Fragments again. When Attempts reaches MAX_ACK_REQUESTS, the sender		Fragments again. When Attempts reaches MAX_ACK_REQUESTS, the sender
	sends an Abort message and releases all resources for the on-going		sends an Abort message and releases all resources for the on-going
	skipping to change at page 39, line 32 ¶		skipping to change at page 38, line 46 ¶
	to allow several SCHC ACK retries if the All-1 fragment has not been		to allow several SCHC ACK retries if the All-1 fragment has not been
	received by the SCHC Fragment receiver, and it also assumes that it		received by the SCHC Fragment receiver, and it also assumes that it
	is unlikely that several ACKs become all lost).		is unlikely that several ACKs become all lost).
	8. Padding management		8. Padding management
	Default padding is defined for L2 frame with a variable length of		Default padding is defined for L2 frame with a variable length of
	bytes. Padding is done twice, after compression and in the all-1		bytes. Padding is done twice, after compression and in the all-1
	fragmentation.		fragmentation.
	In compression, the rule and the compression residues are not aligned		In compression, the Compressed Header is generally not a multiple of
	on a byte, but payload following the residue is always a multiple of		bytes in size, but the payload following the Compressed Header is
	8 bits. In that case, padding bits can be added after the payload to		always a multiple of 8 bits (see Figure 4). If needed, padding bits
	reach the first byte boundary. Since the rule and the residue give		can be added after the payload to reach the next byte boundary.
	the length of the SCHC header and payload is always a multiple of 8		Since the Compressed Header (through the Rule ID and the Compression
	bits, the receiver can without ambiguity remove the padding bits		Residue) tells its length and the payload is always a multiple of 8
	which never excide 7 bits.		bits, the receiver can without ambiguity remove the padding bits,
			which never exceed 7 bits.
	SCHC Fragmentation works on a byte aligned (i.e. padded SCHC Packet).		SCHC F/R works on a byte aligned (i.e. padded SCHC Packet).
	Fragmentation header may not be aligned on byte boundary, but each		Fragmentation header may not be aligned on byte boundary, but each
	fragment except the last one (All-1 fragment) must sent the maximum		fragment except the last one (All-1 fragment) must sent the maximum
	bits as possible. Only the last fragment need to introduce padding		bits as possible. Only the last fragment need to introduce padding
	to reach the next boundary limit. Since the SCHC is known to be a		to reach the next boundary limit. Since the SCHC is known to be a
	multiple of 8 bits, the receiver can remove the extra bit to reach		multiple of 8 bits, the receiver can remove the extra bit to reach
	this limit.		this limit.
	Default padding mechanism do not need to send the padding length and		Default padding mechanism do not need to send the padding length and
	can lead to a maximum of 14 bits of padding.		can lead to a maximum of 14 bits of padding.
	skipping to change at page 43, line 51 ¶		skipping to change at page 43, line 15 ¶
	If the payload is small, the TV can be set to 0x0000, the MO set to		If the payload is small, the TV can be set to 0x0000, the MO set to
	"MSB" and the CDA to "LSB".		"MSB" and the CDA to "LSB".
	In other cases, the length SHOULD be sent and the CDA is replaced by		In other cases, the length SHOULD be sent and the CDA is replaced by
	"value-sent".		"value-sent".
	9.11. UDP Checksum field		9.11. UDP Checksum field
	IPv6 mandates a checksum in the protocol above IP. Nevertheless, if		IPv6 mandates a checksum in the protocol above IP. Nevertheless, if
	a more efficient mechanism such as L2 CRC or MIC is carried by or		a more efficient mechanism such as L2 CRC or MIC is carried by or
	over the L2 (such as in the LPWAN SCHC Fragmentation process (see		over the L2 (such as in the LPWAN SCHC F/R process (see Section 7)),
	Section 7)), the UDP checksum transmission can be avoided. In that		the UDP checksum transmission can be avoided. In that case, the TV
	case, the TV is not set, the MO is set to "ignore" and the CDA is set		is not set, the MO is set to "ignore" and the CDA is set to "compute-
	to "compute-checksum".		checksum".
	In other cases, the checksum SHOULD be explicitly sent. The TV is		In other cases, the checksum SHOULD be explicitly sent. The TV is
	not set, the MO is set to "ignore" and the CDF is set to "value-		not set, the MO is set to "ignore" and the CDF is set to "value-
	sent".		sent".
	10. Security considerations		10. Security considerations
	10.1. Security considerations for header compression		10.1. Security considerations for header compression
	A malicious header compression could cause the reconstruction of a		A malicious header compression could cause the reconstruction of a
	wrong packet that does not match with the original one. Such a		wrong packet that does not match with the original one. Such a
	corruption MAY be detected with end-to-end authentication and		corruption MAY be detected with end-to-end authentication and
	integrity mechanisms. Header Compression does not add more security		integrity mechanisms. Header Compression does not add more security
	problem than what is already needed in a transmission. For instance,		problem than what is already needed in a transmission. For instance,
	to avoid an attack, never re-construct a packet bigger than some		to avoid an attack, never re-construct a packet bigger than some
	configured size (with 1500 bytes as generic default).		configured size (with 1500 bytes as generic default).
	10.2. Security considerations for SCHC Fragmentation		10.2. Security considerations for SCHC Fragmentation/Reassembly
	This subsection describes potential attacks to LPWAN SCHC		This subsection describes potential attacks to LPWAN SCHC F/R and
	Fragmentation and suggests possible countermeasures.		suggests possible countermeasures.
	A node can perform a buffer reservation attack by sending a first		A node can perform a buffer reservation attack by sending a first
	SCHC Fragment to a target. Then, the receiver will reserve buffer		SCHC Fragment to a target. Then, the receiver will reserve buffer
	space for the IPv6 packet. Other incoming SCHC Fragmented packets		space for the IPv6 packet. Other incoming SCHC Fragmented packets
	will be dropped while the reassembly buffer is occupied during the		will be dropped while the reassembly buffer is occupied during the
	reassembly timeout. Once that timeout expires, the attacker can		reassembly timeout. Once that timeout expires, the attacker can
	repeat the same procedure, and iterate, thus creating a denial of		repeat the same procedure, and iterate, thus creating a denial of
	service attack. The (low) cost to mount this attack is linear with		service attack. The (low) cost to mount this attack is linear with
	the number of buffers at the target node. However, the cost for an		the number of buffers at the target node. However, the cost for an
	attacker can be increased if individual SCHC Fragments of multiple		attacker can be increased if individual SCHC Fragments of multiple
	skipping to change at page 48, line 42 ¶		skipping to change at page 47, line 51 ¶
	|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |		|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |
	|IPv6 Length |16|1 |Bi| | ignore | comp-length|| |		|IPv6 Length |16|1 |Bi| | ignore | comp-length|| |
	|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |		|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |
	|IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || |		|IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || |
	|IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || [8] |		|IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || [8] |
	|IPv6 DEVprefix |64|1 |Bi|alpha/64 | equal | not-sent || |		|IPv6 DEVprefix |64|1 |Bi|alpha/64 | equal | not-sent || |
	|IPv6 DEViid |64|1 |Bi| | ignore | DEViid || |		|IPv6 DEViid |64|1 |Bi| | ignore | DEViid || |
	|IPv6 APPprefix |64|1 |Bi|gamma/64 | equal | not-sent || |		|IPv6 APPprefix |64|1 |Bi|gamma/64 | equal | not-sent || |
	|IPv6 APPiid |64|1 |Bi|::1000 | equal | not-sent || |		|IPv6 APPiid |64|1 |Bi|::1000 | equal | not-sent || |
	+================+==+==+==+=========+========+============++======+		+================+==+==+==+=========+========+============++======+
	|UDP DEVport |16|1 |Bi|8720 | MSB(12)| LSB(4) || [4] |		|UDP DEVport |16|1 |Bi|8720 | MSB(12)| LSB || [4] |
	|UDP APPport |16|1 |Bi|8720 | MSB(12)| LSB(4) || [4] |		|UDP APPport |16|1 |Bi|8720 | MSB(12)| LSB || [4] |
	|UDP Length |16|1 |Bi| | ignore | comp-length|| |		|UDP Length |16|1 |Bi| | ignore | comp-length|| |
	|UDP checksum |16|1 |Bi| | ignore | comp-chk || |		|UDP checksum |16|1 |Bi| | ignore | comp-chk || |
	+================+==+==+==+=========+========+============++======+		+================+==+==+==+=========+========+============++======+
	Figure 28: Context rules		Figure 28: Context rules
	All the fields described in the three rules depicted on Figure 28 are		All the fields described in the three rules depicted on Figure 28 are
	present in the IPv6 and UDP headers. The DEViid-DID value is found		present in the IPv6 and UDP headers. The DEViid-DID value is found
	in the L2 header.		in the L2 header.
	skipping to change at page 62, line 9 ¶		skipping to change at page 61, line 9 ¶
	--->* ABORT		--->* ABORT
	Only Uplink		Only Uplink
	Inactivity_Timer = expires		Inactivity_Timer = expires
	~~~~~~~~~~~~~~~~~~~~~~~~~~		~~~~~~~~~~~~~~~~~~~~~~~~~~
	Send Abort		Send Abort
	Figure 43: Receiver State Machine for the ACK-on-Error Mode		Figure 43: Receiver State Machine for the ACK-on-Error Mode
	Appendix D. SCHC Parameters - Ticket #15		Appendix D. SCHC Parameters - Ticket #15
	This gives the list of parameters that need to be defined in the		This section gives the list of parameters that need to be defined in
	technology-specific documents, technology developper must evaluate		the technology-specific documents, technology developers must
	that L2 has strong enough integrity checking to match SCHC's		evaluate that L2 has strong enough integrity checking to match SCHC's
	assumption:		assumption:
	o LPWAN Architecture. Explain the SCHC entities (Compression and		o LPWAN Architecture. Explain the SCHC entities (Compression and
	Fragmentation), how/where are they be represented in the		Fragmentation), how/where are they be represented in the
	corresponding technology architecture.		corresponding technology architecture.
	o L2 fragmentation decision		o L2 fragmentation decision
	o Rule ID number of rules		o Rule ID number of rules
	skipping to change at page 62, line 37 ¶		skipping to change at page 61, line 37 ¶
	o Define the number of bits FCN (N) and DTag (T)		o Define the number of bits FCN (N) and DTag (T)
	o The MIC algorithm to be used and the size if different from the		o The MIC algorithm to be used and the size if different from the
	default CRC32		default CRC32
	o Retransmission Timer duration		o Retransmission Timer duration
	o Inactivity Timer duration		o Inactivity Timer duration
	o Define the MAX_ACK_REQUEST (number of attemps)		o Define the MAX_ACK_REQUEST (number of attempts)
	o Use of padding or not and how and when to use it		o Use of padding or not and how and when to use it
	o Take into account that the length of rule-id + N + T + W when		o Take into account that the length of rule-id + N + T + W when
	possible is good to have a multiple of 8 bits to complete a byte		possible is good to have a multiple of 8 bits to complete a byte
	and avoid padding		and avoid padding
	o In the ACK format to have a length for Rule-ID + T + W bit into a		o In the ACK format to have a length for Rule-ID + T + W bit into a
	complete number of byte to do optimization more easily		complete number of byte to do optimization more easily
			o The technology documents will describe if Rule ID is constrained
			by any alignment
	And the following parameters need to be addressed in another document		And the following parameters need to be addressed in another document
	but not forcely in the technology-specific one:		but not forcely in the technology-specific one:
	o The way the contexts are provisioning		o The way the contexts are provisioning
	o The way the Rules as generated		o The way the Rules as generated
	Appendix E. Note		Appendix E. Note
	Carles Gomez has been funded in part by the Spanish Government		Carles Gomez has been funded in part by the Spanish Government
	(Ministerio de Educacion, Cultura y Deporte) through the Jose		(Ministerio de Educacion, Cultura y Deporte) through the Jose
	Castillejo grant CAS15/00336, and by the ERDF and the Spanish		Castillejo grant CAS15/00336, and by the ERDF and the Spanish
	Government through project TEC2016-79988-P. Part of his contribution		Government through project TEC2016-79988-P. Part of his contribution
	to this work has been carried out during his stay as a visiting		to this work has been carried out during his stay as a visiting
	scholar at the Computer Laboratory of the University of Cambridge.		scholar at the Computer Laboratory of the University of Cambridge.
End of changes. 70 change blocks.
	207 lines changed or deleted		209 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/