< draft-ietf-lpwan-ipv6-static-context-hc-21.txt   draft-ietf-lpwan-ipv6-static-context-hc-22.txt >
lpwan Working Group A. Minaburo lpwan Working Group A. Minaburo
Internet-Draft Acklio Internet-Draft Acklio
Intended status: Standards Track L. Toutain Intended status: Standards Track L. Toutain
Expires: January 24, 2020 IMT-Atlantique Expires: May 3, 2020 IMT-Atlantique
C. Gomez C. Gomez
Universitat Politecnica de Catalunya Universitat Politecnica de Catalunya
D. Barthel D. Barthel
Orange Labs Orange Labs
JC. Zuniga JC. Zuniga
SIGFOX SIGFOX
July 23, 2019 October 31, 2019
Static Context Header Compression (SCHC) and fragmentation for LPWAN, Static Context Header Compression (SCHC) and fragmentation for LPWAN,
application to UDP/IPv6 application to UDP/IPv6
draft-ietf-lpwan-ipv6-static-context-hc-21 draft-ietf-lpwan-ipv6-static-context-hc-22
Abstract Abstract
This document defines the Static Context Header Compression (SCHC) This document defines the Static Context Header Compression (SCHC)
framework, which provides both header compression and fragmentation framework, which provides both header compression and fragmentation
functionalities. SCHC has been designed for Low Power Wide Area functionalities. SCHC has been designed 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 both in
the LPWAN device and the network side. This document defines a the LPWAN device and in the network infrastructure side. This
header compression mechanism and its application to compress IPv6/UDP document defines a header compression mechanism and its application
headers. to compress IPv6/UDP headers.
This document also specifies a fragmentation and reassembly mechanism This document also specifies a fragmentation and reassembly mechanism
that is used to support the IPv6 MTU requirement over the LPWAN that is used to support the IPv6 MTU requirement over the LPWAN
technologies. Fragmentation is needed for IPv6 datagrams that, after technologies. Fragmentation is needed for IPv6 datagrams that, after
SCHC compression or when such compression was not possible, still SCHC compression or when such compression was not possible, still
exceed the layer-2 maximum payload size. exceed the layer-2 maximum payload size.
The SCHC header compression and fragmentation mechanisms are The SCHC header compression and fragmentation mechanisms are
independent of the specific LPWAN technology over which they are independent of the specific LPWAN technology over which they are
used. This document defines generic functionalities and offers used. This document defines generic functionalities and offers
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 24, 2020. This Internet-Draft will expire on May 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 45 skipping to change at page 2, line 45
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 5 3. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. SCHC overview . . . . . . . . . . . . . . . . . . . . . . . . 8 5. SCHC overview . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. SCHC Packet format . . . . . . . . . . . . . . . . . . . 10 5.1. SCHC Packet format . . . . . . . . . . . . . . . . . . . 10
5.2. Functional mapping . . . . . . . . . . . . . . . . . . . 10 5.2. Functional mapping . . . . . . . . . . . . . . . . . . . 11
6. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Compression/Decompression . . . . . . . . . . . . . . . . . . 12 7. Compression/Decompression . . . . . . . . . . . . . . . . . . 12
7.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . . 12 7.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . . 13
7.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . . 14 7.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . . 15
7.3. Packet processing . . . . . . . . . . . . . . . . . . . . 15 7.3. Packet processing . . . . . . . . . . . . . . . . . . . . 15
7.4. Matching operators . . . . . . . . . . . . . . . . . . . 17 7.4. Matching operators . . . . . . . . . . . . . . . . . . . 17
7.5. Compression Decompression Actions (CDA) . . . . . . . . . 17 7.5. Compression Decompression Actions (CDA) . . . . . . . . . 18
7.5.1. processing fixed-length fields . . . . . . . . . . . 18 7.5.1. processing fixed-length fields . . . . . . . . . . . 19
7.5.2. processing variable-length fields . . . . . . . . . . 18 7.5.2. processing variable-length fields . . . . . . . . . . 19
7.5.3. not-sent CDA . . . . . . . . . . . . . . . . . . . . 19 7.5.3. not-sent CDA . . . . . . . . . . . . . . . . . . . . 20
7.5.4. value-sent CDA . . . . . . . . . . . . . . . . . . . 19 7.5.4. value-sent CDA . . . . . . . . . . . . . . . . . . . 20
7.5.5. mapping-sent CDA . . . . . . . . . . . . . . . . . . 19 7.5.5. mapping-sent CDA . . . . . . . . . . . . . . . . . . 20
7.5.6. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 20 7.5.6. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 21
7.5.7. DevIID, AppIID CDA . . . . . . . . . . . . . . . . . 20 7.5.7. DevIID, AppIID CDA . . . . . . . . . . . . . . . . . 21
7.5.8. Compute-* . . . . . . . . . . . . . . . . . . . . . . 20 7.5.8. Compute-* . . . . . . . . . . . . . . . . . . . . . . 21
8. Fragmentation/Reassembly . . . . . . . . . . . . . . . . . . 21 8. Fragmentation/Reassembly . . . . . . . . . . . . . . . . . . 22
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2. SCHC F/R Protocol Elements . . . . . . . . . . . . . . . 21 8.2. SCHC F/R Protocol Elements . . . . . . . . . . . . . . . 22
8.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 21 8.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 22
8.2.2. Tiles, Windows, Bitmaps, Timers, Counters . . . . . . 22 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters . . . . . . 23
8.2.3. Integrity Checking . . . . . . . . . . . . . . . . . 24 8.2.3. Integrity Checking . . . . . . . . . . . . . . . . . 25
8.2.4. Header Fields . . . . . . . . . . . . . . . . . . . . 25 8.2.4. Header Fields . . . . . . . . . . . . . . . . . . . . 26
8.3. SCHC F/R Message Formats . . . . . . . . . . . . . . . . 27 8.3. SCHC F/R Message Formats . . . . . . . . . . . . . . . . 28
8.3.1. SCHC Fragment format . . . . . . . . . . . . . . . . 27 8.3.1. SCHC Fragment format . . . . . . . . . . . . . . . . 28
8.3.2. SCHC ACK format . . . . . . . . . . . . . . . . . . . 28 8.3.2. SCHC ACK format . . . . . . . . . . . . . . . . . . . 30
8.3.3. SCHC ACK REQ format . . . . . . . . . . . . . . . . . 31 8.3.3. SCHC ACK REQ format . . . . . . . . . . . . . . . . . 32
8.3.4. SCHC Sender-Abort format . . . . . . . . . . . . . . 31 8.3.4. SCHC Sender-Abort format . . . . . . . . . . . . . . 33
8.3.5. SCHC Receiver-Abort format . . . . . . . . . . . . . 32 8.3.5. SCHC Receiver-Abort format . . . . . . . . . . . . . 33
8.4. SCHC F/R modes . . . . . . . . . . . . . . . . . . . . . 33 8.4. SCHC F/R modes . . . . . . . . . . . . . . . . . . . . . 34
8.4.1. No-ACK mode . . . . . . . . . . . . . . . . . . . . . 33 8.4.1. No-ACK mode . . . . . . . . . . . . . . . . . . . . . 34
8.4.2. ACK-Always mode . . . . . . . . . . . . . . . . . . . 35 8.4.2. ACK-Always mode . . . . . . . . . . . . . . . . . . . 36
8.4.3. ACK-on-Error mode . . . . . . . . . . . . . . . . . . 41 8.4.3. ACK-on-Error mode . . . . . . . . . . . . . . . . . . 43
9. Padding management . . . . . . . . . . . . . . . . . . . . . 48 9. Padding management . . . . . . . . . . . . . . . . . . . . . 51
10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 49 10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 52
10.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 49 10.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 52
10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 50 10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 52
10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 50 10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 52
10.4. Payload Length field . . . . . . . . . . . . . . . . . . 50 10.4. Payload Length field . . . . . . . . . . . . . . . . . . 53
10.5. Next Header field . . . . . . . . . . . . . . . . . . . 51 10.5. Next Header field . . . . . . . . . . . . . . . . . . . 53
10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 51 10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 53
10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 51 10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 53
10.7.1. IPv6 source and destination prefixes . . . . . . . . 51 10.7.1. IPv6 source and destination prefixes . . . . . . . . 54
10.7.2. IPv6 source and destination IID . . . . . . . . . . 52 10.7.2. IPv6 source and destination IID . . . . . . . . . . 54
10.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . 52 10.8. IPv6 extension headers . . . . . . . . . . . . . . . . . 54
10.9. UDP source and destination port . . . . . . . . . . . . 52 10.9. UDP source and destination ports . . . . . . . . . . . . 55
10.10. UDP length field . . . . . . . . . . . . . . . . . . . . 53 10.10. UDP length field . . . . . . . . . . . . . . . . . . . . 55
10.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 53 10.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 55
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
12. Security considerations . . . . . . . . . . . . . . . . . . . 54 12. Security considerations . . . . . . . . . . . . . . . . . . . 56
12.1. Security considerations for SCHC 12.1. Security considerations for SCHC
Compression/Decompression . . . . . . . . . . . . . . . 54 Compression/Decompression . . . . . . . . . . . . . . . 56
12.1.1. Forged SCHC Packet . . . . . . . . . . . . . . . . . 56
12.1.2. Compressed packet size as a side channel to guess a
secret token . . . . . . . . . . . . . . . . . . . . 57
12.1.3. decompressed packet different from the original
packet . . . . . . . . . . . . . . . . . . . . . . . 58
12.2. Security considerations for SCHC 12.2. Security considerations for SCHC
Fragmentation/Reassembly . . . . . . . . . . . . . . . . 55 Fragmentation/Reassembly . . . . . . . . . . . . . . . . 58
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 12.2.1. Buffer reservation attack . . . . . . . . . . . . . 58
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 12.2.2. Corrupt Fragment attack . . . . . . . . . . . . . . 59
14.1. Normative References . . . . . . . . . . . . . . . . . . 56 12.2.3. Fragmentation as a way to bypass Network Inspection 59
14.2. Informative References . . . . . . . . . . . . . . . . . 56 12.2.4. Privacy issues associated with SCHC header fields . 59
Appendix A. Compression Examples . . . . . . . . . . . . . . . . 57 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60
Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 60 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
Appendix C. Fragmentation State Machines . . . . . . . . . . . . 68 14.1. Normative References . . . . . . . . . . . . . . . . . . 60
Appendix D. SCHC Parameters . . . . . . . . . . . . . . . . . . 74 14.2. Informative References . . . . . . . . . . . . . . . . . 61
Appendix E. Supporting multiple window sizes for fragmentation . 76 Appendix A. Compression Examples . . . . . . . . . . . . . . . . 61
Appendix F. Downlink SCHC Fragment transmission . . . . . . . . 76 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 Appendix C. Fragmentation State Machines . . . . . . . . . . . . 71
Appendix D. SCHC Parameters . . . . . . . . . . . . . . . . . . 77
Appendix E. Supporting multiple window sizes for fragmentation . 79
Appendix F. ACK-Always and ACK-on-Error on quasi-bidirectional
links . . . . . . . . . . . . . . . . . . . . . . . 79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81
1. Introduction 1. Introduction
This document defines the Static Context Header Compression (SCHC) This document defines the Static Context Header Compression (SCHC)
framework, which provides both header compression and fragmentation framework, which provides both header compression and fragmentation
functionalities. SCHC has been designed for Low Power Wide Area functionalities. SCHC has been designed for Low Power Wide Area
Networks (LPWAN). Networks (LPWAN).
LPWAN technologies impose some strict limitations on traffic. For LPWAN technologies impose some strict limitations on traffic. For
instance, devices sleep most of the time and may only receive data instance, devices sleep most of the time and may only receive data
during short periods of time after transmission, in order to preserve during short periods of time after transmission, in order to preserve
battery. LPWAN technologies are also characterized by a greatly battery. LPWAN technologies are also characterized by a greatly
reduced data unit and/or payload size (see [RFC8376]). reduced data unit and/or payload size (see [RFC8376]).
Header compression is needed for efficient Internet connectivity to Header compression is needed for efficient Internet connectivity to a
the node within an LPWAN network. The following properties of LPWAN node within an LPWAN network. The following properties of LPWAN
networks can be exploited to get an efficient header compression: networks can be exploited to get an efficient header compression:
o The network topology is star-oriented, which means that all o The network topology is star-oriented, which means that all
packets between the same source-destination pair follow the same packets between the same source-destination pair follow the same
path. For the needs of this document, the architecture can simply path. For the needs of this document, the architecture can simply
be described as Devices (Dev) exchanging information with LPWAN be described as Devices (Dev) exchanging information with LPWAN
Application Servers (App) through a Network Gateway (NGW). Application Servers (App) through a Network Gateway (NGW).
o Because devices embed built-in applications, the traffic flows to o Because devices embed built-in applications, the traffic flows to
be compressed are known in advance. Indeed, new applications are be compressed are known in advance. Indeed, new applications are
less frequently installed in an LPWAN device, than they are in a less frequently installed in an LPWAN device, than they are in a
computer or smartphone. general-purpose computer or smartphone.
SCHC compression uses a Context (a set of Rules) in which information SCHC compression uses a Context (a set of Rules) in which information
about header fields is stored. This Context is static: the values of about header fields is stored. This Context is static: the values of
the header fields and the actions to do compression/decompression do the header fields and the actions to do compression/decompression do
not change over time. This avoids the need for complex not change over time. This avoids the need for complex
resynchronization mechanisms. Indeed, a return path may be more resynchronization mechanisms. Indeed, a return path may be more
restricted/expensive, sometimes completely unavailable [RFC8376]. A restricted/expensive, sometimes completely unavailable [RFC8376]. A
compression protocol that relies on feedback is not compatible with compression protocol that relies on feedback is not compatible with
the characteristics of such LPWANs. the characteristics of such LPWANs.
skipping to change at page 5, line 18 skipping to change at page 5, line 27
Furthermore, some LPWAN technologies do not provide a fragmentation Furthermore, some LPWAN technologies do not provide a fragmentation
functionality; to support the IPv6 MTU requirement of 1280 bytes functionality; to support the IPv6 MTU requirement of 1280 bytes
[RFC8200], they require a fragmentation protocol at the adaptation [RFC8200], they require a fragmentation protocol at the adaptation
layer below IPv6. Accordingly, this document defines an optional layer below IPv6. Accordingly, this document defines an optional
fragmentation/reassembly mechanism for LPWAN technologies to support fragmentation/reassembly mechanism for LPWAN technologies to support
the IPv6 MTU requirement. the IPv6 MTU requirement.
This document defines generic functionality and offers flexibility This document defines generic functionality and offers flexibility
with regard to parameters settings and mechanism choices. with regard to parameters settings and mechanism choices.
Technology-specific settings and product-specific choices are Technology-specific settings are expected to be grouped into Profiles
expected to be grouped into Profiles specified in other documents. specified in other documents.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. LPWAN Architecture 3. LPWAN Architecture
LPWAN technologies have similar network architectures but different LPWAN network architectures are similar among them, but each LPWAN
terminologies. Using the terminology defined in [RFC8376], we can technology names architecture elements differently. In this
identify different types of entities in a typical LPWAN network, see document, we use terminology from [RFC8376], which identifies the
Figure 1: following entities in a typical LPWAN network (see Figure 1):
o Devices (Dev) are the end-devices or hosts (e.g. sensors, o Devices (Dev) are the end-devices or hosts (e.g. sensors,
actuators, etc.). There can be a very high density of devices per actuators, etc.). There can be a very high density of devices per
radio gateway. radio gateway.
o The Radio Gateway (RGW), which is the end point of the constrained o The Radio Gateway (RGW) is the end point of the constrained link.
link.
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. Radio Gateway and the Internet.
o Application Server (App) o Application Server (App) is the end point of the application level
+------+ protocol on the Internet side.
() () () | |LPWAN-|
() () () () / \ +---------+ | AAA | () () () |
() () () () () () / \======| ^ |===|Server| +-----------+ () () () () / \ +---------+
() () () | | <--|--> | +------+ |Application| () () () () () () / \======| ^ | +-----------+
() () () | | <--|--> | |Application|
() () () () / \==========| v |=============| (App) | () () () () / \==========| v |=============| (App) |
() () () / \ +---------+ +-----------+ () () () / \ +---------+ +-----------+
Dev Radio Gateways NGW Dev Radio Gateways NGW
Figure 1: LPWAN Architecture as shown in RFC8376 Figure 1: LPWAN Architecture, simplified from that shown in RFC8376
4. Terminology 4. Terminology
This section defines the terminology and acronyms used in this This section defines the terminology and acronyms used in this
document. It extends the terminology of [RFC8376]. document. It extends the terminology of [RFC8376].
The SCHC acronym is pronounced like "sheek" in English (or "chic" in The SCHC acronym is pronounced like "sheek" in English (or "chic" in
French). Therefore, this document writes "a SCHC Packet" instead of French). Therefore, this document writes "a SCHC Packet" instead of
"an SCHC Packet". "an SCHC Packet".
skipping to change at page 7, line 26 skipping to change at page 7, line 26
Field Description applies to. Field Description applies to.
o FL: Field Length is the length of the packet header field. It is o FL: Field Length is the length of the packet header field. It is
expressed in bits for header fields of fixed lengths or as a type expressed in bits for header fields of fixed lengths or as a type
(e.g. variable, token length, ...) for field lengths that are (e.g. variable, token length, ...) for field lengths that are
unknown at the time of Rule creation. The length of a header unknown at the time of Rule creation. The length of a header
field is defined in the corresponding protocol specification (such field is defined in the corresponding protocol specification (such
as IPv6 or UDP). as IPv6 or UDP).
o FP: when a Field is expected to appear multiple times in a header, o FP: when a Field is expected to appear multiple times in a header,
Field Position specifies the occurence this Field Description Field Position specifies the occurrence this Field Description
applies to (for example, first uri-path option, second uri-path, applies to (for example, first uri-path option, second uri-path,
etc. in a CoAP header). etc. in a CoAP header).
o IID: Interface Identifier. See the IPv6 addressing architecture o IID: Interface Identifier. See the IPv6 addressing architecture
[RFC7136] [RFC7136]
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 does not It is provided by an underlying LPWAN technology. It does not
necessarily correspond to the OSI model definition of Layer 2. necessarily correspond to the OSI model definition of Layer 2.
skipping to change at page 8, line 43 skipping to change at page 8, line 43
matched with the value of a header field. matched with the value of a header field.
o Up: Uplink direction for compression/decompression, from the Dev o Up: Uplink direction for compression/decompression, from the Dev
SCHC C/D to the network SCHC C/D. SCHC C/D to the network SCHC C/D.
Additional terminology for the optional SCHC Fragmentation / Additional terminology for the optional SCHC Fragmentation /
Reassembly mechanism (SCHC F/R) is found in Section 8.2. Reassembly mechanism (SCHC F/R) is found in Section 8.2.
5. SCHC overview 5. SCHC overview
SCHC can be characterized as an adaptation layer between IPv6 and the SCHC can be characterized as an adaptation layer between an upper
underlying LPWAN technology. SCHC comprises two sublayers (i.e. the layer (typically, IPv6) and an underlying layer (typically, an LPWAN
Compression sublayer and the Fragmentation sublayer), as shown in technology). SCHC comprises two sublayers (i.e. the Compression
Figure 2. sublayer and the Fragmentation sublayer), as shown in Figure 2.
+----------------+ +----------------+
| IPv6 | | IPv6 |
+- +----------------+ +- +----------------+
| | Compression | | | Compression |
SCHC < +----------------+ SCHC < +----------------+
| | Fragmentation | | | Fragmentation |
+- +----------------+ +- +----------------+
|LPWAN technology| |LPWAN technology|
+----------------+ +----------------+
Figure 2: Protocol stack comprising IPv6, SCHC and an LPWAN Figure 2: Protocol stack comprising IPv6, SCHC and an LPWAN
technology technology
Before a packet (e.g. an IPv6 packet) is transmitted, header Before an upper layer packet (e.g. an IPv6 packet) is transmitted to
compression is first applied. The resulting packet is called a SCHC the underlying layer, header compression is first attempted. The
Packet, whether or not any compression is performed. If the SCHC resulting packet is called a SCHC Packet, whether or not any
Packet is to be fragmented, the optional SCHC Fragmentation MAY be compression is performed. If needed by the underlying layer, the
applied to the SCHC Packet. The inverse operations take place at the optional SCHC Fragmentation MAY be applied to the SCHC Packet. The
receiver. This process is illustrated in Figure 3. inverse operations take place at the receiver. This process is
illustrated in Figure 3.
A packet (e.g. an IPv6 packet) A packet (e.g. an IPv6 packet)
| ^ | ^
v | v |
+------------------+ +--------------------+ +------------------+ +--------------------+
| SCHC Compression | | SCHC Decompression | | SCHC Compression | | SCHC Decompression |
+------------------+ +--------------------+ +------------------+ +--------------------+
| ^ | ^
| If no fragmentation (*) | | If no fragmentation (*) |
+-------------- SCHC Packet -------------->| +-------------- SCHC Packet -------------->|
| | | |
v | v |
+--------------------+ +-----------------+ +--------------------+ +-----------------+
| SCHC Fragmentation | | SCHC Reassembly | | SCHC Fragmentation | | SCHC Reassembly |
+--------------------+ +-----------------+ +--------------------+ +-----------------+
| ^ | ^ | ^ | ^
| | | | | | | |
| +-------------- SCHC ACK -------------+ | | +---------- SCHC ACK (+) -------------+ |
| | | |
+-------------- SCHC Fragments -------------------+ +-------------- SCHC Fragments -------------------+
Sender Receiver Sender Receiver
*: the decision to use Fragmentation or not is left to each Profile. *: the decision to not use SCHC Fragmentation is left to each Profile.
+: optional, depends on Fragmentation mode.
Figure 3: SCHC operations at the SENDER and the RECEIVER Figure 3: SCHC operations at the Sender and the Receiver
5.1. SCHC Packet format 5.1. SCHC Packet format
The SCHC Packet is composed of the Compressed Header followed by the The SCHC Packet is composed of the Compressed Header followed by the
payload from the original packet (see Figure 4). The Compressed payload from the original packet (see Figure 4). The Compressed
Header itself is composed of the Rule ID and a Compression Residue, Header itself is composed of the Rule ID and a Compression Residue,
which is the output of compressing the packet header with that Rule which is the output of compressing the packet header with that Rule
(see Section 7). The Compression Residue may be empty. Both the (see Section 7). The Compression Residue may be empty. Both the
Rule ID and the Compression Residue potentially have a variable size, Rule ID and the Compression Residue potentially have a variable size,
and are not necessarily a multiple of bytes in size. and are not necessarily a multiple of bytes in size.
|------- Compressed Header -------| |------- Compressed Header -------|
+---------------------------------+--------------------+ +---------------------------------+--------------------+
| Rule ID | Compression Residue | Payload | | Rule ID | Compression Residue | Payload |
+---------------------------------+--------------------+ +---------------------------------+--------------------+
Figure 4: SCHC Packet Figure 4: SCHC Packet
5.2. Functional mapping 5.2. Functional mapping
Figure 5 below maps the functional elements of Figure 3 onto the Figure 5 maps the functional elements of Figure 3 onto the LPWAN
LPWAN architecture elements of Figure 1. architecture elements of Figure 1.
Dev App Dev App
+----------------+ +----+ +----+ +----+ +----------------+ +----+ +----+ +----+
| App1 App2 App3 | |App1| |App2| |App3| | App1 App2 App3 | |App1| |App2| |App3|
| | | | | | | | | | | | | | | |
| UDP | |UDP | |UDP | |UDP | | UDP | |UDP | |UDP | |UDP |
| IPv6 | |IPv6| |IPv6| |IPv6| | IPv6 | |IPv6| |IPv6| |IPv6|
| | | | | | | | | | | | | | | |
|SCHC C/D and F/R| | | | | | | |SCHC C/D and F/R| | | | | | |
+--------+-------+ +----+ +----+ +----+ +--------+-------+ +----+ +----+ +----+
| +---+ +---+ +----+ +----+ . . . | +---+ +---+ +----+ +----+ . . .
+~ |RGW| === |NGW| == |SCHC| == |SCHC|...... Internet .... +~ |RGW| === |NGW| == |SCHC| == |SCHC|...... Internet ....
+---+ +---+ |F/R | |C/D | +---+ +---+ |F/R | |C/D |
+----+ +----+ +----+ +----+
Figure 5: Architecture Figure 5: Architecture
SCHC C/D and SCHC F/R are located on both sides of the LPWAN SCHC C/D and SCHC F/R are located on both sides of the LPWAN
transmission, i.e. on the Dev side and on the Network side. transmission, hereafter called "the Dev side" and "the Network
infrastructure side".
The operation in the Uplink direction is as follows. The Device The operation in the Uplink direction is as follows. The Device
application uses IPv6 or IPv6/UDP protocols. Before sending the application uses IPv6 or IPv6/UDP protocols. Before sending the
packets, the Dev compresses their headers using SCHC C/D and, if the packets, the Dev compresses their headers using SCHC C/D and, if the
SCHC Packet resulting from the compression needs to be fragmented by SCHC Packet resulting from the compression needs to be fragmented by
SCHC, SCHC F/R is performed (see Section 8). The resulting SCHC SCHC, SCHC F/R is performed (see Section 8). The resulting SCHC
Fragments are sent to an LPWAN Radio Gateway (RGW) which forwards Fragments are sent to an LPWAN Radio Gateway (RGW) which forwards
them to a Network Gateway (NGW). The NGW sends the data to a SCHC F/ them to a Network Gateway (NGW). The NGW sends the data to a SCHC F/
R for re-assembly (if needed) and then to the SCHC C/D for R for re-assembly (if needed) and then to the SCHC C/D for
decompression. After decompression, the packet can be sent over the decompression. After decompression, the packet can be sent over the
Internet to one or several LPWAN Application Servers (App). Internet to one or several LPWAN Application Servers (App).
The SCHC F/R and C/D on the Network side can be located in the NGW, The SCHC F/R and C/D on the Network infrastructure side can be part
or somewhere else as long as a tunnel is established between them and of the NGW, or located in the Internet as long as a tunnel is
the NGW. For some LPWAN technologies, it may be suitable to locate established between them and the NGW. For some LPWAN technologies,
the SCHC F/R functionality nearer the NGW, in order to better deal it may be suitable to locate the SCHC F/R functionality nearer the
with time constraints of such technologies. NGW, in order to better deal with time constraints of such
technologies.
The SCHC C/Ds on both sides MUST share the same set of Rules. So The SCHC C/Ds on both sides MUST share the same set of Rules. So
MUST the SCHC F/Rs on both sides. MUST the SCHC F/Rs on both sides.
The operation in the Downlink direction is similar to that in the The operation in the Downlink direction is similar to that in the
Uplink direction, only reverting the order in which the architecture Uplink direction, only reversing the order in which the architecture
elements are traversed. elements are traversed.
6. Rule ID 6. Rule ID
Rule IDs identify the Rules used for Compression/Decompression or for Rule IDs identify the Rules used for Compression/Decompression or for
Fragmentation/Reassembly. Fragmentation/Reassembly.
The scope of a Rule ID is the link between the SCHC Compressor and The scope of the Rule ID of a Compression/Decompression Rule is the
the SCHC Decompressor, or between the SCHC Fragmenter and the SCHC link between the SCHC C/D in a given Dev and the corresponding SCHC
Reassembler. C/D in the Network insfractructure side. The scope of the Rule ID of
a Fragmentation/Reassembly Rule is the link between the SCHC F/R in a
given Dev and the corresponding SCHC F/R in the Network
insfractructure side. If such a link is bidirectional, the scope
includes both directions.
Inside their scopes, Rules for Compression/Decompression and Rules
for Fragmentation/Reassembly share the same Rule ID space.
The size of the Rule IDs is not specified in this document, as it is The size of the Rule IDs is not specified in this document, as it is
implementation-specific and can vary according to the LPWAN implementation-specific and can vary according to the LPWAN
technology and the number of Rules, among others. It is defined in technology and the number of Rules, among others. It is defined in
Profiles. Profiles.
The Rule IDs are used: The Rule IDs are used:
o For SCHC C/D, to identify the Rule (i.e., the set of Field o For SCHC C/D, to identify the Rule (i.e., the set of Field
Descriptions) that is used to compress a packet header. Descriptions) that is used to compress a packet header.
* At least one Rule ID MUST be allocated to tagging packets for * At least one Rule ID MUST be allocated to tagging packets for
which SCHC compression was not possible (no matching Rule was which SCHC compression was not possible (no matching
found). compression Rule was found).
o In SCHC F/R, to identify the specific mode and settings of F/R for o In SCHC F/R, to identify the specific mode and settings of F/R for
one direction of traffic (Up or Dw). one direction of traffic (Up or Dw).
* When F/R is used for both communication directions, at least * When F/R is used for both communication directions, at least
two Rule ID values are needed for F/R, one per direction of two Rule ID values are needed for F/R, one per direction of
traffic. traffic. This is because F/R may entail control messages
flowing in the reverse direction compared to data traffic.
7. Compression/Decompression 7. Compression/Decompression
Compression with SCHC is based on using a set of Rules, called the Compression with SCHC is based on using a set of Rules, called the
Context, to compress or decompress headers. SCHC avoids Context Context, to compress or decompress headers. SCHC avoids Context
synchronization traffic, which consumes considerable bandwidth in synchronization traffic, which consumes considerable bandwidth in
other header compression mechanisms such as RoHC [RFC5795]. Since other header compression mechanisms such as RoHC [RFC5795]. Since
the content of packets is highly predictable in LPWAN networks, the content of packets is highly predictable in LPWAN networks,
static Contexts may be stored beforehand. The Contexts MUST be static Contexts may be stored beforehand. The Contexts MUST be
stored at both ends, and they can be learned by a provisioning stored at both ends, and they can be learned by a provisioning
skipping to change at page 14, line 7 skipping to change at page 14, line 35
Rule is created or a type if the length is variable. The length Rule is created or a type if the length is variable. The length
of a header field is defined by its own protocol specification of a header field is defined by its own protocol specification
(e.g. IPv6 or UDP). If the length is variable, the type defines (e.g. IPv6 or UDP). If the length is variable, the type defines
the process to compute the length and its unit (bits, bytes...). the process to compute the length and its unit (bits, bytes...).
o Field Position (FP): most often, a field only occurs once in a o Field Position (FP): most often, a field only occurs once in a
packet header. However, some fields may occur multiple times. An packet header. However, some fields may occur multiple times. An
example is the uri-path of CoAP. FP indicates which occurrence example is the uri-path of CoAP. FP indicates which occurrence
this Field Description applies to. If FP is not specified in the this Field Description applies to. If FP is not specified in the
Field Description, it takes the default value of 1. The value 1 Field Description, it takes the default value of 1. The value 1
designates the first occurence. The value 0 is special. It means designates the first occurrence. The value 0 is special. It
"don't care", see Section 7.3. means "don't care", see Section 7.3.
o A Direction Indicator (DI) indicates the packet direction(s) this o A Direction Indicator (DI) indicates the packet direction(s) this
Field Description applies to. Three values are possible: Field Description applies to. Three values are possible:
* UPLINK (Up): this Field Description is only applicable to * UPLINK (Up): this Field Description is only applicable to
packets sent by the Dev to the App, packets sent by the Dev to the App,
* DOWNLINK (Dw): this Field Description is only applicable to * DOWNLINK (Dw): this Field Description is only applicable to
packets sent from the App to the Dev, packets sent from the App to the Dev,
skipping to change at page 14, line 48 skipping to change at page 15, line 27
decompression functions. The set of CDAs defined in this document decompression functions. The set of CDAs defined in this document
can be found in Section 7.5. can be found in Section 7.5.
7.2. Rule ID for SCHC C/D 7.2. Rule ID for SCHC C/D
Rule IDs are sent by the compression function in one side and are Rule IDs are sent by the compression function in one side and are
received for the decompression function in the other side. In SCHC received for the decompression function in the other side. In SCHC
C/D, the Rule IDs are specific to the Context related to one Dev. C/D, the Rule IDs are specific to the Context related to one Dev.
Hence, multiple Dev instances, which refer to different header Hence, multiple Dev instances, which refer to different header
compression Contexts, MAY reuse the same Rule ID for different Rules. compression Contexts, MAY reuse the same Rule ID for different Rules.
On the network side, in order to identify the correct Rule to be On the Network infrastructure side, in order to identify the correct
applied, the SCHC Decompressor needs to associate the Rule ID with Rule to be applied, the SCHC Decompressor needs to associate the Rule
the Dev identifier. Similarly, the SCHC Compressor on the network ID with the Dev identifier. Similarly, the SCHC Compressor on the
side first identifies the destination Dev before looking for the Network infrastructure side first identifies the destination Dev
appropriate compression Rule (and associated Rule ID) in the Context before looking for the appropriate compression Rule (and associated
of that Dev. Rule ID) in the Context of that Dev.
7.3. Packet processing 7.3. Packet processing
The compression/decompression process follows several steps: The compression/decompression process follows several phases:
o Compression Rule selection: the set of Rules is browsed to o Compression Rule selection: the general idea is to browse the Rule
identify which Rule will be used to compress the packet header. set to find a Rule that has a matching Field Descriptor (given the
The Rule is selected by matching the Fields Descriptions to the DI and FP) for all and only those header fields that appear in the
packet header. The detailed steps are the following: packet being compressed. The detailed algorithm is the following:
* The first step is to check the Field Identifiers (FID). If any * The first step is to check the Field Identifiers (FID). If any
header field of the packet being examined cannot be matched header field of the packet being examined cannot be matched
with a Field Description with the correct FID, the Rule MUST be with a Field Description with the correct FID, the Rule MUST be
disregarded. If any Field Description in the Rule has a FID disregarded. If any Field Description in the Rule has a FID
that cannot be matched to one of the header fields of the that cannot be matched to one of the header fields of the
packet being examined, the Rule MUST be disregarded. packet being examined, the Rule MUST be disregarded.
* The next step is to match the Field Descriptions by their * The next step is to match the Field Descriptions by their
direction, using the Direction Indicator (DI). If any field of direction, using the Direction Indicator (DI). If any field of
skipping to change at page 15, line 39 skipping to change at page 16, line 18
Field Position (FP). If any field of the packet header cannot Field Position (FP). If any field of the packet header cannot
be matched with a Field Description with the correct FID, DI be matched with a Field Description with the correct FID, DI
and FP, the Rule MUST be disregarded. and FP, the Rule MUST be disregarded.
The value 0 for FP means "don't care", i.e. the comparison of The value 0 for FP means "don't care", i.e. the comparison of
this Field Description's FP with the position of the field of this Field Description's FP with the position of the field of
the packet header being compressed returns True, whatever that the packet header being compressed returns True, whatever that
position. FP=0 can be useful to build compression Rules for position. FP=0 can be useful to build compression Rules for
protocols headers in which some fields order is irrelevant. An protocols headers in which some fields order is irrelevant. An
example could be uri-queries in CoAP. Care needs to be example could be uri-queries in CoAP. Care needs to be
exercised when writing Rules containing FP=0 values. Inded, it exercised when writing Rules containing FP=0 values. Indeed,
may result in decompressed packets having fields ordered it may result in decompressed packets having fields ordered
differently compared to the original packet. differently compared to the original packet.
* Once each header field has been associated with a Field * Once each header field has been associated with a Field
Description with matching FID, DI and FP, each packet field's Description with matching FID, DI and FP, each packet field's
value is then compared to the corresponding Target Value (TV) value is then compared to the corresponding Target Value (TV)
stored in the Rule for that specific field, using the matching stored in the Rule for that specific field, using the matching
operator (MO). If every field in the packet header satisfies operator (MO). If every field in the packet header satisfies
the corresponding matching operators (MO) of a Rule (i.e. all the corresponding matching operators (MO) of a Rule (i.e. all
MO results are True), that Rule is used for compressing the MO results are True), that Rule is valid for use to compress
header. Otherwise, the Rule MUST be disregarded. the header. Otherwise, the Rule MUST be disregarded.
* If no eligible compression Rule is found, then the header MUST This specification does not prevent multiple Rules from
be sent in its entirety using the Rule ID of the "default" Rule matching the above steps and therefore being valid for use.
dedicated to this purpose. Sending an uncompressed header may Whether multiple valid Rules are allowed or not and what to do
require SCHC F/R. in the case of multiple valid Rules are left to the
implementation. As long as the same Rule set is installed at
both ends, this degree of freedom does not constitute an
interoperability issue.
o Compression: each field of the header is compressed according to * If no valid compression Rule is found, then the header MUST be
the Compression/Decompression Actions (CDAs). The fields are sent in its entirety using the Rule ID of the "default" Rule
compressed in the order that the Field Descriptions appear in the dedicated to this purpose. Sending an uncompressed header is
Rule. The compression of each field results in a residue, which likely to require SCHC F/R.
may be empty. The Compression Residue for the packet header is
the concatenation of the non-empty residues for each field of the o Compression: if a valid Rule was found, each field of the header
header, in the order the Field Descriptions appear in the Rule. is compressed according to the Compression/Decompression Actions
(CDAs) of the Rule. The fields are compressed in the order that
the Field Descriptions appear in the Rule. The compression of
each field results in a residue, which may be empty. The
Compression Residue for the packet header is the concatenation of
the non-empty residues for each field of the header, in the order
the Field Descriptions appear in the Rule. The order in which the
Field Descriptions appear in the Rule is therefore semantically
important.
|------------------- Compression Residue -------------------| |------------------- Compression Residue -------------------|
+-----------------+-----------------+-----+-----------------+ +-----------------+-----------------+-----+-----------------+
| field 1 residue | field 2 residue | ... | field N residue | | field 1 residue | field 2 residue | ... | field N residue |
+-----------------+-----------------+-----+-----------------+ +-----------------+-----------------+-----+-----------------+
Figure 7: Compression Residue structure Figure 7: Compression Residue structure
o Sending: The Rule ID is sent to the other end followed by the o Sending: The Rule ID is sent to the other end followed by the
Compression Residue (which could be empty) or the uncompressed Compression Residue (which could be empty) or the uncompressed
header, and directly followed by the payload (see Figure 4). The header, and directly followed by the payload (see Figure 4). The
way the Rule ID is sent will be specified in the Profile and is way the Rule ID is sent will be specified in the Profile and is
out of the scope of the present document. For example, it could out of the scope of the present document. For example, it could
be included in an L2 header or sent as part of the L2 payload. be included in an L2 header or sent as part of the L2 payload.
o Decompression: when decompressing, on the network side the SCHC C/ o Decompression: when decompressing, on the Network infrastructure
D needs to find the correct Rule based on the L2 address; in this side the SCHC C/D needs to find the correct Rule based on the L2
way, it can use the DevIID and the Rule ID. On the Dev side, only address of the Dev; in this way, it can use the DevIID and the
the Rule ID is needed to identify the correct Rule since the Dev Rule ID. On the Dev side, only the Rule ID is needed to identify
typically only holds Rules that apply to itself. the correct Rule since the Dev typically only holds Rules that
apply to itself.
The receiver identifies the sender through its device-id or source This Rule describes the compressed header format. From this, the
identifier (e.g. MAC address, if it exists) and selects the Rule decompressor determines the order of the residues, the fixed-sized
using the Rule ID. This Rule describes the compressed header or variable-sized nature of each residue (see Section 7.5.2), and
format and associates the received residues to each of the header the size of the fixed-sized residues.
fields. For each field in the header, the receiver applies the
CDA action associated to that field in order to reconstruct the From the received compressed header, it can therefore retrieve all
original header field value. The CDA application order can be the residue values and associate them to the corresponding header
different from the order in which the fields are listed in the fields.
Rule. In particular, Compute-* MUST be applied after the
application of the CDAs of all the fields it computes on. For each field in the header, the receiver applies the CDA action
associated to that field in order to reconstruct the original
header field value. The CDA application order can be different
from the order in which the fields are listed in the Rule. In
particular, Compute-* MUST be applied after the application of the
CDAs of all the fields it computes on.
7.4. Matching operators 7.4. Matching operators
Matching Operators (MOs) are functions used by both SCHC C/D Matching Operators (MOs) are functions used by both SCHC C/D
endpoints. They are not typed and can be applied to integer, string endpoints. They are not typed and can be applied to integer, string
or any other data type. The result of the operation can either be or any other data type. The result of the operation can either be
True or False. MOs are defined as follows: True or False. MOs are defined as follows:
o equal: The match result is True if the field value in the packet o equal: The match result is True if the field value in the packet
matches the TV. matches the TV.
o ignore: No matching is attempted between the field value in the o ignore: No matching is attempted between the field value in the
packet and the TV in the Rule. The result is always true. packet and the TV in the Rule. The result is always true.
o MSB(x): A match is obtained if the most significant x bits of the o MSB(x): A match is obtained if the most significant (leftmost) x
packet header field value are equal to the TV in the Rule. The x bits of the packet header field value are equal to the TV in the
parameter of the MSB MO indicates how many bits are involved in Rule. The x parameter of the MSB MO indicates how many bits are
the comparison. If the FL is described as variable, the length involved in the comparison. If the FL is described as variable,
must be a multiple of the unit. For example, x must be multiple the x parameter must be a multiple of the FL unit. For example, x
of 8 if the unit of the variable length is in bytes. must be multiple of 8 if the unit of the variable length is bytes.
o match-mapping: With match-mapping, the Target Value is a list of o match-mapping: With match-mapping, the Target Value is a list of
values. Each value of the list is identified by an index. values. Each value of the list is identified by an index.
Compression is achieved by sending the index instead of the Compression is achieved by sending the index instead of the
original header field value. This operator matches if the header original header field value. This operator matches if the header
field value is equal to one of the values in the target list. field value is equal to one of the values in the target list.
7.5. Compression Decompression Actions (CDA) 7.5. Compression Decompression Actions (CDA)
The Compression Decompression Action (CDA) describes the actions The Compression Decompression Action (CDA) describes the actions
skipping to change at page 18, line 13 skipping to change at page 19, line 8
Table 1: Compression and Decompression Actions Table 1: Compression and Decompression Actions
Table 1 summarizes the basic actions that can be used to compress and Table 1 summarizes the basic actions that can be used to compress and
decompress a field. The first column shows the action's name. The decompress a field. The first column shows the action's name. The
second and third columns show the compression and decompression second and third columns show the compression and decompression
behaviors for each action. behaviors for each action.
7.5.1. processing fixed-length fields 7.5.1. processing fixed-length fields
If the field is identified in the Field Description as being of fixed If the field is identified in the Field Description as being of fixed
length, then aplying the CDA to compress this field results in a length, then applying the CDA to compress this field results in a
fixed amount of bits. The residue for that field is simply the bits fixed amount of bits. The residue for that field is simply the bits
resulting from applying the CDA to the field. This value may be resulting from applying the CDA to the field. This value may be
empty (e.g. not-sent CDA), in which case the field residue is absent empty (e.g. not-sent CDA), in which case the field residue is absent
from the Compression Residue. from the Compression Residue.
|- field residue -| |- field residue -|
+-----------------+ +-----------------+
| value | | value |
+-----------------+ +-----------------+
Figure 8: fixed sized field residue structure Figure 8: fixed sized field residue structure
7.5.2. processing variable-length fields 7.5.2. processing variable-length fields
If the field is identified in the Field Description as being of If the field is identified in the Field Description as being of
variable length, then aplying the CDA to compress this field may variable length, then applying the CDA to compress this field may
result in a value of fixed size (e.g. not-sent or mapping-sent) or of result in a value of fixed size (e.g. not-sent or mapping-sent) or of
variable size (e.g. value-sent or LSB). In the latter case, the variable size (e.g. value-sent or LSB). In the latter case, the
residue for that field is the bits that result from applying the CDA residue for that field is the bits that result from applying the CDA
to the field, preceded with the size of the value. The most to the field, preceded with the size of the value. The most
significant bit of the size is stored first (left of the residue bit significant bit of the size is stored to the left (leftmost bit of
field). the residue field).
|--- field residue ---| |--- field residue ---|
+-------+-------------+ +-------+-------------+
| size | value | | size | value |
+-------+-------------+ +-------+-------------+
Figure 9: variable sized field residue structure Figure 9: variable sized field residue structure
The size (using the unit defined in the FL) is encoded on 4, 12 or 28 The size (using the unit defined in the FL) is encoded on 4, 12 or 28
bits as follows: bits as follows:
skipping to change at page 19, line 32 skipping to change at page 20, line 26
The compressor does not send any residue for a field on which not- The compressor does not send any residue for a field on which not-
sent compression is applied. 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.
7.5.4. value-sent CDA 7.5.4. value-sent CDA
The value-sent action can be used when the field value is not known The value-sent action can be used when the field value is not known
by both the Compressor and the Decompressor. The value is sent in by both the Compressor and the Decompressor. The field is sent in
its entirety. its entirety, using the same bit order as in the original packet
header.
If this action is performed on a variable length field, the size of If this action is performed on a variable length field, the size of
the residue value (using the units defined in FL) MUST be sent as the residue value (using the units defined in FL) MUST be sent as
described in Section 7.5.2. described in Section 7.5.2.
This action is generally used with the "ignore" MO. This action is generally used with the "ignore" MO.
7.5.5. mapping-sent CDA 7.5.5. mapping-sent CDA
The mapping-sent action is used to send an index (the index into the The mapping-sent action is used to send an 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
action is used together with the "match-mapping" MO. action 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. The mapping-sent CDA the TV for a match with the header field value. The mapping-sent CDA
then sends the corresponding index as the field residue. The most then sends the corresponding index as the field residue. The most
significant bit of the index is stored first (left of the residue bit significant bit of the index is stored to the left (leftmost bit of
field). the residue field).
On the decompressor side, the CDA uses the received index to restore On the decompressor side, the CDA uses the received index to restore
the field value by looking up the list in the TV. 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.
The first element in the list MUST be represented by index value 0,
and successive elements in the list MUST have indices incremented by
1.
7.5.6. LSB CDA 7.5.6. LSB CDA
The LSB action is used together with the "MSB(x)" MO to avoid sending The LSB action is used together with the "MSB(x)" MO to avoid sending
the most significant part of the packet field if that part is already the most significant part of the packet field if that part is already
known by the receiving end. known by the receiving end.
The compressor sends the Least Significant Bits as the field residue The compressor sends the Least Significant Bits as the field residue
value. The number of bits sent is the original header field length value. The number of bits sent is the original header field length
minus the length specified in the MSB(x) MO. minus the length specified in the MSB(x) MO. The bits appear in the
residue in the same bit order as in the original packet header.
The decompressor concatenates the x most significant bits of Target The decompressor concatenates the x most significant bits of Target
Value and the received residue value. Value and the received residue value.
If this action is performed on a variable length field, the size of If this action is performed on a variable length field, the size of
the residue value (using the units defined in FL) MUST be sent as the residue value (using the units defined in FL) MUST be sent as
described in Section 7.5.2. described in Section 7.5.2.
7.5.7. DevIID, AppIID CDA 7.5.7. DevIID, AppIID CDA
skipping to change at page 21, line 18 skipping to change at page 22, line 15
8. Fragmentation/Reassembly 8. Fragmentation/Reassembly
8.1. Overview 8.1. Overview
In LPWAN technologies, the L2 MTU typically ranges from tens to In LPWAN technologies, the L2 MTU typically ranges from tens to
hundreds of bytes. Some of these technologies do not have an hundreds of bytes. Some of these technologies do not have an
internal fragmentation/reassembly mechanism. internal fragmentation/reassembly mechanism.
The optional SCHC Fragmentation/Reassembly (SCHC F/R) functionality The optional SCHC Fragmentation/Reassembly (SCHC F/R) functionality
enables such LPWAN technologies to comply with the IPv6 MTU enables such LPWAN technologies to comply with the IPv6 MTU
requirement of 1280 bytes [RFC8200]. It is optional to implement. requirement of 1280 bytes [RFC8200]. It is OPTIONAL to implement per
If it is not needed, its description can be safely ignored. this specification, but Profiles may specify that it is REQUIRED.
This specification includes several SCHC F/R modes, which allow for a This specification includes several SCHC F/R modes, which allow for a
range of reliability options such as optional SCHC Fragment range of reliability options such as optional SCHC Fragment
retransmission. More modes may be defined in the future. retransmission. More modes may be defined in the future.
The same SCHC F/R mode MUST be used for all SCHC Fragments of a SCHC The same SCHC F/R mode MUST be used for all SCHC Fragments of a given
Packet. This document does not specify which mode(s) are to be used SCHC Packet. This document does not specify which mode(s) must be
over a specific LPWAN technology. That information will be given in implemented and used over a specific LPWAN technology. That
Profiles. information will be given in Profiles.
SCHC allows transmitting non-fragmented SCHC Packet concurrently with
fragmented SCHC Packets. In addition, SCHC F/R provides protocol
elements that allow transmitting several fragmented SCHC Packets
concurrently, i.e. interleaving the transmission of fragments from
different fragmented SCHC Packets. A Profile MAY restrict the latter
behavior.
The L2 Word size (see Section 4) determines the encoding of some The L2 Word size (see Section 4) determines the encoding of some
messages. SCHC F/R usually generates SCHC Fragments and SCHC ACKs messages. SCHC F/R usually generates SCHC Fragments and SCHC ACKs
that are multiples of L2 Words. that are multiples of L2 Words.
8.2. SCHC F/R Protocol Elements 8.2. SCHC F/R Protocol Elements
This subsection describes the different elements that are used to This subsection describes the different elements that are used to
enable the SCHC F/R functionality defined in this document. These enable the SCHC F/R functionality defined in this document. These
elements include the SCHC F/R messages, tiles, windows, bitmaps, elements include the SCHC F/R messages, tiles, windows, bitmaps,
skipping to change at page 22, line 16 skipping to change at page 23, line 22
o SCHC ACK REQ: A request by the sender for a SCHC ACK from the o SCHC ACK REQ: A request by the sender for a SCHC ACK from the
receiver. receiver.
o SCHC Sender-Abort: A message by the sender telling the receiver o SCHC Sender-Abort: A message by the sender telling the receiver
that it has aborted the transmission of a fragmented SCHC Packet. that it has aborted the transmission of a fragmented SCHC Packet.
o SCHC Receiver-Abort: A message by the receiver to tell the sender o SCHC Receiver-Abort: A message by the receiver to tell the sender
to abort the transmission of a fragmented SCHC Packet. to abort the transmission of a fragmented SCHC Packet.
The format of these messages is provided in Section 8.3.
8.2.2. Tiles, Windows, Bitmaps, Timers, Counters 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters
8.2.2.1. Tiles 8.2.2.1. Tiles
The SCHC Packet is fragmented into pieces, hereafter called tiles. The SCHC Packet is fragmented into pieces, hereafter called tiles.
The tiles MUST be non-empty and pairwise disjoint. Their union MUST The tiles MUST be non-empty and pairwise disjoint. Their union MUST
be equal to the SCHC Packet. be equal to the SCHC Packet.
See Figure 10 for an example. See Figure 10 for an example.
SCHC Packet SCHC Packet
+----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+
Tiles | | | | | | | | | | | | | | Tiles | | | | | | | | | | | | | |
+----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+
Figure 10: a SCHC Packet fragmented in tiles Figure 10: a SCHC Packet fragmented in tiles
Modes (see Section 8.4) MAY place additional constraints on tile
sizes.
Each SCHC Fragment message carries at least one tile in its Payload, Each SCHC Fragment message carries at least one tile in its Payload,
if the Payload field is present. if the Payload field is present.
8.2.2.2. Windows 8.2.2.2. Windows
Some SCHC F/R modes may handle successive tiles in groups, called Some SCHC F/R modes may handle successive tiles in groups, called
windows. windows.
If windows are used If windows are used
o all the windows of a SCHC Packet, except the last one, MUST o all the windows of a SCHC Packet, except the last one, MUST
contain the same number of tiles. This number is WINDOW_SIZE. contain the same number of tiles. This number is WINDOW_SIZE.
o WINDOW_SIZE MUST be specified in a Profile. o WINDOW_SIZE MUST be specified in a Profile.
o the windows are numbered. o the windows are numbered.
o their numbers MUST increase from 0 upward, from the start of the o their numbers MUST increment by 1 from 0 upward, from the start of
SCHC Packet to its end. the SCHC Packet to its end.
o the last window MUST contain WINDOW_SIZE tiles or less. o the last window MUST contain WINDOW_SIZE tiles or less.
o tiles are numbered within each window. o tiles are numbered within each window.
o the tile indices MUST decrement from WINDOW_SIZE - 1 downward, o the tile indices MUST decrement by 1 from WINDOW_SIZE - 1
looking from the start of the SCHC Packet toward its end. downward, looking from the start of the SCHC Packet toward its
end.
o each tile of a SCHC Packet is therefore uniquely identified by a o each tile of a SCHC Packet is therefore uniquely identified by a
window number and a tile index within this window. window number and a tile index within this window.
See Figure 11 for an example. See Figure 11 for an example.
+---------------------------------------------...-------------+ +---------------------------------------------...-------------+
| SCHC Packet | | SCHC Packet |
+---------------------------------------------...-------------+ +---------------------------------------------...-------------+
Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 | 3 | Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 | 3 |
Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|-- 28 -| Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|-- 28 -|
Figure 11: a SCHC Packet fragmented in tiles grouped in 28 windows, Figure 11: a SCHC Packet fragmented in tiles grouped in 29 windows,
with WINDOW_SIZE = 5 with WINDOW_SIZE = 5
Appendix E discusses the benefits of selecting one among multiple
window sizes depending on the size of the SCHC Packet to be
fragmented.
When windows are used When windows are used
o Bitmaps (see Section 8.2.2.3) MAY be sent back by the receiver to o Bitmaps (see Section 8.2.2.3) MAY be sent back by the receiver to
the sender in a SCHC ACK message. the sender in a SCHC ACK message.
o A Bitmap corresponds to exactly one Window. o A Bitmap corresponds to exactly one Window.
8.2.2.3. Bitmaps 8.2.2.3. Bitmaps
Each bit in the Bitmap for a window corresponds to a tile in the Each bit in the Bitmap for a window corresponds to a tile in the
skipping to change at page 24, line 4 skipping to change at page 25, line 19
left-most position corresponds to the tile numbered WINDOW_SIZE - 1. left-most position corresponds to the tile numbered WINDOW_SIZE - 1.
Consecutive bits, going right, correspond to sequentially decreasing Consecutive bits, going right, correspond to sequentially decreasing
tile indices. In Bitmaps for windows that are not the last one of a tile indices. In Bitmaps for windows that are not the last one of a
SCHC Packet, the bit at the right-most position corresponds to the SCHC Packet, the bit at the right-most position corresponds to the
tile numbered 0. In the Bitmap for the last window, the bit at the tile numbered 0. In the Bitmap for the last window, the bit at the
right-most position corresponds either to the tile numbered 0 or to a right-most position corresponds either to the tile numbered 0 or to a
tile that is sent/received as "the last one of the SCHC Packet" tile that is sent/received as "the last one of the SCHC Packet"
without explicitly stating its number (see Section 8.3.1.2). without explicitly stating its number (see Section 8.3.1.2).
At the receiver At the receiver
o a bit set to 1 in the Bitmap indicates that a tile associated with o a bit set to 1 in the Bitmap indicates that a tile associated with
that bit position has been correctly received for that window. that bit position has been correctly received for that window.
o a bit set to 0 in the Bitmap indicates that no tile associated o a bit set to 0 in the Bitmap indicates that there has been no tile
with that bit position has been correctly received for that correctly received, associated with that bit position, for that
window. window. Possible reasons include that the tile was not sent at
all, not received, or received with errors.
8.2.2.4. Timers and counters 8.2.2.4. Timers and counters
Some SCHC F/R modes can use the following timers and counters Some SCHC F/R modes can use the following timers and counters
o Inactivity Timer: a SCHC Fragment receiver uses this timer to o Inactivity Timer: a SCHC Fragment receiver uses this timer to
abort waiting for a SCHC F/R message. abort waiting for a SCHC F/R message.
o Retransmission Timer: a SCHC Fragment sender uses this timer to o Retransmission Timer: a SCHC Fragment sender uses this timer to
abort waiting for an expected SCHC ACK. abort waiting for an expected SCHC ACK.
o Attempts: this counter counts the requests for SCHC ACKs, up to o Attempts: this counter counts the requests for SCHC ACKs, up to
MAX_ACK_REQUESTS. MAX_ACK_REQUESTS.
8.2.3. Integrity Checking 8.2.3. Integrity Checking
The integrity of the fragmentation-reassembly process of a SCHC The integrity of the fragmentation-reassembly process of a SCHC
Packet MUST be checked at the receive end. By default, integrity Packet MUST be checked at the receive end. By default, integrity
checking is performed by computing a Reassembly Check Sequence (RCS) checking is performed by computing a Reassembly Check Sequence (RCS)
of the SCHC Packet at the sender side before fragmentation and based on the SCHC Packet at the sender side and transmitting it to
transmitting it to the receiver for comparison with the RCS locally the receiver for comparison with the RCS locally computed after
computed after reassembly. reassembly.
The RCS supports UDP checksum elision by SCHC C/D (see The RCS supports UDP checksum elision by SCHC C/D (see
Section 10.11). Section 10.11).
The CRC32 polynomial 0xEDB88320 (i.e. the reverse representation of The CRC32 polynomial 0xEDB88320 (i.e. the reversed polynomial
the polynomial used e.g. in the Ethernet standard [RFC3385]) is representation, which is used e.g. in the Ethernet standard
RECOMMENDED as the default algorithm for computing the RCS. [ETHERNET]) is RECOMMENDED as the default algorithm for computing the
Nevertheless, other RCS lengths or other algorithms MAY be required RCS. Nevertheless, other RCS lengths or other algorithms MAY be
by the Profile. required by the Profile.
The RCS MUST be computed on the full SCHC Packet concatenated with The RCS MUST be computed on the full SCHC Packet concatenated with
the padding bits, if any, of the SCHC Fragment carrying the last the padding bits, if any, of the SCHC Fragment carrying the last
tile. The rationale is that the SCHC reassembler has no way of tile. The rationale is that the SCHC reassembler has no way of
knowing the boundary between the last tile and the padding bits. knowing the boundary between the last tile and the padding bits.
Indeed, this requires decompressing the SCHC Packet, which is out of Indeed, this requires decompressing the SCHC Packet, which is out of
the scope of the SCHC reassembler. the scope of the SCHC reassembler.
Note that the concatenation of the complete SCHC Packet and the Note that the concatenation of the complete SCHC Packet and any
potential padding bits of the last SCHC Fragment does not generally padding bits, if present, of the last SCHC Fragment does not
constitute an integer number of bytes. For implementers to be able generally constitute an integer number of bytes. For implementers to
to use byte-oriented CRC libraries, it is RECOMMENDED that the be able to use byte-oriented CRC libraries, it is RECOMMENDED that
concatenation of the complete SCHC Packet and the last fragment the concatenation of the complete SCHC Packet and any last fragment
potential padding bits be zero-extended to the next byte boundary and padding bits be zero-extended to the next byte boundary and that the
that the RCS be computed on that byte array. A Profile MAY specify RCS be computed on that byte array. A Profile MAY specify another
another behavior. behavior.
8.2.4. Header Fields 8.2.4. Header Fields
The SCHC F/R messages contain the following fields (see the formats The SCHC F/R messages contain the following fields (see the formats
in Section 8.3): in Section 8.3):
o Rule ID: this field is present in all the SCHC F/R messages. It o Rule ID: this field is present in all the SCHC F/R messages. It
is used to identify is used to identify
* that a SCHC F/R message is being carried, as opposed to an * that a SCHC F/R message is being carried, as opposed to an
unfragmented SCHC Packet, unfragmented SCHC Packet,
* which SCHC F/R mode is used * which SCHC F/R mode is used
* and for this mode * in case this mode uses windows, what the value of WINDOW_SIZE
is,
+ if windows are used and what the value of WINDOW_SIZE is, * what other optional fields are present and what the field sizes
are.
+ what other optional fields are present and what the field The Rule ID tells apart a non-fragmented SCHC Packet from SCHC
sizes are. Fragments. It will also tell apart SCHC Fragments of fragmented
SCHC Packets that use different SCHC F/R modes or different
parameters. Interleaved transmission of these is therefore
possible.
The Rule ID allows SCHC F/R interleaving non-fragmented SCHC All SCHC F/R messages pertaining to the same SCHC Packet MUST bear
Packets and SCHC Fragments that carry other SCHC Packets, or the same Rule ID.
interleaving SCHC Fragments that use different SCHC F/R modes or
different parameters.
o Datagram Tag (DTag). Its size (called T, in bits) is defined by o Datagram Tag (DTag). This field allows differentiating SCHC F/R
each Profile for each Rule ID. When T is 0, the DTag field does messages belonging to different SCHC Packets that may be using the
not appear in the SCHC F/R messages and the DTag value is defined same Rule ID simultaneously. Hence, it allows interleaving
as 0. fragments of a new SCHC Packet with fragments of a previous SCHC
Packet under the same Rule ID.
When T is 0, there can be only one fragmented SCHC Packet in The size of the DTag field (called T, in bits) is defined by each
transit for a given Rule ID. Profile for each Rule ID. When T is 0, the DTag field does not
appear in the SCHC F/R messages and the DTag value is defined as
0.
When T is 0, there can be no more than one fragmented SCHC Packet
in transit for each fragmentation Rule ID.
If T is not 0, DTag If T is not 0, DTag
* MUST be set to the same value for all the SCHC F/R messages * MUST be set to the same value for all the SCHC F/R messages
related to the same fragmented SCHC Packet, related to the same fragmented SCHC Packet,
* MUST be set to different values for SCHC F/R messages related * MUST be set to different values for SCHC F/R messages related
to different SCHC Packets that are being fragmented under the to different SCHC Packets that are being fragmented under the
same Rule ID and the transmission of which may overlap. same Rule ID, and whose transmission may overlap.
A sequence counter that is incremented for each new fragmented
SCHC Packet, counting from 0 to up to (2^T)-1 and wrapping back to
0 is RECOMMENDED for maximum traceability and avoidance of
ambiguity.
A flow of SCHC F/R messages with a given Rule ID and DTag value
pair MUST NOT interfere with the operation of a SCHC F/R instance
that uses another Rule ID and DTag value pair.
o W: The W field is optional. It is only present if windows are o W: The W field is optional. It is only present if windows are
used. Its presence and size (called M, in bits) is defined by used. Its presence and size (called M, in bits) is defined by
each SCHC F/R mode and each Profile for each Rule ID. each SCHC F/R mode and each Profile for each Rule ID.
This field carries information pertaining to the window a SCHC F/R This field carries information pertaining to the window a SCHC F/R
message relates to. If present, W MUST carry the same value for message relates to. If present, W MUST carry the same value for
all the SCHC F/R messages related to the same window. Depending all the SCHC F/R messages related to the same window. Depending
on the mode and Profile, W may carry the full window number, or on the mode and Profile, W may carry the full window number, or
just the least significant bit or any other partial representation just the least significant bit or any other partial representation
skipping to change at page 27, line 41 skipping to change at page 29, line 9
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~
| Fragment Header | Fragment Payload | padding (as needed) | Fragment Header | Fragment Payload | padding (as needed)
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~
Figure 12: SCHC Fragment general format Figure 12: SCHC Fragment general format
8.3.1.1. Regular SCHC Fragment 8.3.1.1. Regular SCHC Fragment
The Regular SCHC Fragment format is shown in Figure 13. Regular SCHC The Regular SCHC Fragment format is shown in Figure 13. Regular SCHC
Fragments are generally used to carry tiles that are not the last one Fragments are generally used to carry tiles that are not the last one
of a SCHC Packet. The DTag field and the W field are optional. of a SCHC Packet. The DTag field and the W field are OPTIONAL, their
presence is specified by each mode and Profile.
|--- SCHC Fragment Header ----| |--- SCHC Fragment Header ----|
|-- T --|-M-|-- N --| |-- T --|-M-|-- N --|
+-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ +-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W | FCN | Fragment Payload | padding (as needed) | Rule ID | DTag | W | FCN | Fragment Payload | padding (as needed)
+-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ +-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~
Figure 13: Detailed Header Format for Regular SCHC Fragments Figure 13: Detailed Header Format for Regular SCHC Fragments
The FCN field MUST NOT contain all bits set to 1. The FCN field MUST NOT contain all bits set to 1.
skipping to change at page 28, line 15 skipping to change at page 29, line 32
The Fragment Payload of a SCHC Fragment with FCN equal to 0 (called The Fragment Payload of a SCHC Fragment with FCN equal to 0 (called
an All-0 SCHC Fragment) MUST be distinguishable by size from a SCHC an All-0 SCHC Fragment) MUST be distinguishable by size from a SCHC
ACK REQ message (see Section 8.3.3) that has the same T, M and N ACK REQ message (see Section 8.3.3) that has the same T, M and N
values, even in the presence of padding. This condition is met if values, even in the presence of padding. This condition is met if
the Payload is at least the size of an L2 Word. This condition is the Payload is at least the size of an L2 Word. This condition is
also met if the SCHC Fragment Header is a multiple of L2 Words. also met if the SCHC Fragment Header is a multiple of L2 Words.
8.3.1.2. All-1 SCHC Fragment 8.3.1.2. All-1 SCHC Fragment
The All-1 SCHC Fragment format is shown in Figure 14. The sender The All-1 SCHC Fragment format is shown in Figure 14. The sender
generally uses the All-1 SCHC Fragment format for the message that uses the All-1 SCHC Fragment format for the message that completes
completes the emission of a fragmented SCHC Packet. The DTag field, the emission of a fragmented SCHC Packet. The DTag field, the W
the W field, the RCS field and the Payload are optional. At least field, the RCS field and the Payload are OPTIONAL, their presence is
one of RCS field or Payload MUST be present. The FCN field is all specified by each mode and Profile. At least one of RCS field or
ones. Payload MUST be present. The FCN field is all ones.
|-------- SCHC Fragment Header -------| |-------- SCHC Fragment Header -------|
|-- T --|-M-|-- N --|-- U --| |-- T --|-M-|-- N --|-- U --|
+-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ +-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W | 11..1 | RCS | Frag Payload | pad. (as needed) | Rule ID | DTag | W | 11..1 | RCS | Frag Payload | pad. (as needed)
+-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ +-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~
(FCN) (FCN)
Figure 14: Detailed Header Format for the All-1 SCHC Fragment Figure 14: Detailed Header Format for the All-1 SCHC Fragment
The All-1 SCHC Fragment message MUST be distinguishable by size from The All-1 SCHC Fragment message MUST be distinguishable by size from
a SCHC Sender-Abort message (see Section 8.3.4) that has the same T, a SCHC Sender-Abort message (see Section 8.3.4) that has the same T,
M and N values, even in the presence of padding. This condition is M and N values, even in the presence of padding. This condition is
met if the RCS is present and is at least the size of an L2 Word, or met if the RCS is present and is at least the size of an L2 Word, or
if the Payload is present and at least the size an L2 Word. This if the Payload is present and at least the size an L2 Word. This
condition is also met if the SCHC Sender-Abort Header is a multiple condition is also met if the SCHC Sender-Abort Header is a multiple
of L2 Words. of L2 Words.
8.3.2. SCHC ACK format 8.3.2. SCHC ACK format
The SCHC ACK message is shown in Figure 15. The DTag field, the W The SCHC ACK message is shown in Figure 15. The DTag field and the W
field and the Compressed Bitmap field are optional. The Compressed field are OPTIONAL, their presence is specified by each mode and
Bitmap field can only be present in SCHC F/R modes that use windows. Profile. The Compressed Bitmap field MUST be present in SCHC F/R
modes that use windows, and MUST NOT be present in other modes.
|---- SCHC ACK Header ----| |---- SCHC ACK Header ----|
|-- T --|-M-| 1 | |-- T --|-M-| 1 |
+--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ +--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W |C=1| padding as needed (success) | Rule ID | DTag | W |C=1| padding as needed (success)
+--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ +--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
+--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ +--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
| Rule ID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure) | Rule ID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure)
+--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ +--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
skipping to change at page 31, line 27 skipping to change at page 32, line 41
| Rule ID | DTag | W |C=0|1| transmitted SCHC ACK | Rule ID | DTag | W |C=0|1| transmitted SCHC ACK
+--- ... -+- ... -+---+---+-+ +--- ... -+- ... -+---+---+-+
next L2 Word boundary ->| next L2 Word boundary ->|
Figure 19: Example of a SCHC ACK message, no missing tile Figure 19: Example of a SCHC ACK message, no missing tile
8.3.3. SCHC ACK REQ format 8.3.3. SCHC ACK REQ format
The SCHC ACK REQ is used by a sender to request a SCHC ACK from the The SCHC ACK REQ is used by a sender to request a SCHC ACK from the
receiver. Its format is shown in Figure 20. The DTag field and the receiver. Its format is shown in Figure 20. The DTag field and the
W field are optional. The FCN field is all zero. W field are OPTIONAL, their presence is specified by each mode and
Profile. The FCN field is all zero.
|---- SCHC ACK REQ Header ----| |---- SCHC ACK REQ Header ----|
|-- T --|-M-|-- N --| |-- T --|-M-|-- N --|
+-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W | 0..0 | padding (as needed) (no payload) | Rule ID | DTag | W | 0..0 | padding (as needed) (no payload)
+-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
Figure 20: SCHC ACK REQ format Figure 20: SCHC ACK REQ format
8.3.4. SCHC Sender-Abort format 8.3.4. SCHC Sender-Abort format
When a SCHC Fragment sender needs to abort an on-going fragmented When a SCHC Fragment sender needs to abort an on-going fragmented
SCHC Packet transmission, it sends a SCHC Sender-Abort message to the SCHC Packet transmission, it sends a SCHC Sender-Abort message to the
SCHC Fragment receiver. SCHC Fragment receiver.
The SCHC Sender-Abort format is shown in Figure 21. The DTag field The SCHC Sender-Abort format is shown in Figure 21. The DTag field
and the W field are optional. The FCN field is all ones. and the W field are OPTIONAL, their presence is specified by each
mode and Profile. The FCN field is all ones.
|---- Sender-Abort Header ----| |---- Sender-Abort Header ----|
|-- T --|-M-|-- N --| |-- T --|-M-|-- N --|
+-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W | 11..1 | padding (as needed) | Rule ID | DTag | W | 11..1 | padding (as needed)
+-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
Figure 21: SCHC Sender-Abort format Figure 21: SCHC Sender-Abort format
If the W field is present, If the W field is present,
skipping to change at page 32, line 22 skipping to change at page 33, line 40
The SCHC Sender-Abort MUST NOT be acknowledged. The SCHC Sender-Abort MUST NOT be acknowledged.
8.3.5. SCHC Receiver-Abort format 8.3.5. SCHC Receiver-Abort format
When a SCHC Fragment receiver needs to abort an on-going fragmented When a SCHC Fragment receiver needs to abort an on-going fragmented
SCHC Packet transmission, it transmits a SCHC Receiver-Abort message SCHC Packet transmission, it transmits a SCHC Receiver-Abort message
to the SCHC Fragment sender. to the SCHC Fragment sender.
The SCHC Receiver-Abort format is shown in Figure 22. The DTag field The SCHC Receiver-Abort format is shown in Figure 22. The DTag field
and the W field are optional. and the W field are OPTIONAL, their presence is specified by each
mode and Profile.
|--- Receiver-Abort Header ---| |--- Receiver-Abort Header ---|
|--- T ---|-M-| 1 | |--- T ---|-M-| 1 |
+--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ +--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+
| Rule ID | DTag | W |C=1| 1..1| 1..1 | | Rule ID | DTag | W |C=1| 1..1| 1..1 |
+--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ +--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+
next L2 Word boundary ->|<-- L2 Word -->| next L2 Word boundary ->|<-- L2 Word -->|
Figure 22: SCHC Receiver-Abort format Figure 22: SCHC Receiver-Abort format
skipping to change at page 32, line 34 skipping to change at page 34, line 4
|--- Receiver-Abort Header ---| |--- Receiver-Abort Header ---|
|--- T ---|-M-| 1 | |--- T ---|-M-| 1 |
+--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ +--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+
| Rule ID | DTag | W |C=1| 1..1| 1..1 | | Rule ID | DTag | W |C=1| 1..1| 1..1 |
+--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ +--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+
next L2 Word boundary ->|<-- L2 Word -->| next L2 Word boundary ->|<-- L2 Word -->|
Figure 22: SCHC Receiver-Abort format Figure 22: SCHC Receiver-Abort format
If the W field is present, If the W field is present,
o the fragment receiver MUST set it to all ones. Other values are o the fragment receiver MUST set it to all ones. Other values are
RESERVED. RESERVED.
o if the value is different from all ones, the fragment sender MUST o if the value is different from all ones, the fragment sender MUST
ignore the message. ignore the message.
The SCHC Receiver-Abort has the same header as a SCHC ACK message. The SCHC Receiver-Abort has the same header as a SCHC ACK message.
The bits that follow the SCHC Receiver-Abort Header MUST be as The bits that follow the SCHC Receiver-Abort Header MUST be as
follows follows
o if the Header does not end at an L2 Word boundary, append bits set o if the Header does not end at an L2 Word boundary, append bits set
to 1 as needed to reach the next L2 Word boundary to 1 as needed to reach the next L2 Word boundary
o append exactly one more L2 Word with bits all set to ones o append exactly one more L2 Word with bits all set to ones
Such a bit pattern never occurs in a regular SCHC ACK. This is how Such a bit pattern never occurs in a legit SCHC ACK. This is how the
the fragment sender recognizes a SCHC Receiver-Abort. fragment sender recognizes a SCHC Receiver-Abort.
The SCHC Receiver-Abort MUST NOT be acknowledged. The SCHC Receiver-Abort MUST NOT be acknowledged.
8.4. SCHC F/R modes 8.4. SCHC F/R modes
This specification includes several SCHC F/R modes, which This specification includes several SCHC F/R modes, which
o allow for a range of reliability options, such as optional SCHC o allow for a range of reliability options, such as optional SCHC
Fragment retransmission Fragment retransmission
o support various LPWAN characteristics, including variable MTU. o support various LPWAN characteristics, such as links with variable
MTU or unidirectional links.
More modes may be defined in the future. More modes may be defined in the future.
Appendix B provides examples of fragmentation sessions based on the
modes described hereafter.
Appendix C provides examples of Finite Sate Machines implementing the
SCHC F/R modes decribed hereafter.
8.4.1. No-ACK mode 8.4.1. No-ACK mode
The No-ACK mode has been designed under the assumption that data unit The No-ACK mode has been designed under the assumption that data unit
out-of-sequence delivery does not occur between the entity performing out-of-sequence delivery does not occur between the entity performing
fragmentation and the entity performing reassembly. This mode fragmentation and the entity performing reassembly. This mode
supports LPWAN technologies that have a variable MTU. supports LPWAN technologies that have a variable MTU.
In No-ACK mode, there is no communication from the fragment receiver In No-ACK mode, there is no communication from the fragment receiver
to the fragment sender. The sender transmits all the SCHC Fragments to the fragment sender. The sender transmits all the SCHC Fragments
without expecting acknowledgement. without expecting any acknowledgement. Therefore, No-ACK does not
require bidirectional links: unidirectional links are just fine.
In No-ACK mode, only the All-1 SCHC Fragment is padded as needed. In No-ACK mode, only the All-1 SCHC Fragment is padded as needed.
The other SCHC Fragments are intrinsically aligned to L2 Words. The other SCHC Fragments are intrinsically aligned to L2 Words.
The tile sizes are not required to be uniform. Windows are not used. The tile sizes are not required to be uniform. Windows are not used.
The Retransmission Timer is not used. The Attempts counter is not The Retransmission Timer is not used. The Attempts counter is not
used. used.
Each Profile MUST specify which Rule ID value(s) correspond to SCHC Each Profile MUST specify which Rule ID value(s) correspond to SCHC
F/R messages operating in this mode. F/R messages operating in this mode.
skipping to change at page 34, line 4 skipping to change at page 35, line 30
The value of N (size of the FCN field) is RECOMMENDED to be 1. The value of N (size of the FCN field) is RECOMMENDED to be 1.
Each Profile, for each Rule ID value, MUST define Each Profile, for each Rule ID value, MUST define
o the size of the DTag field, o the size of the DTag field,
o the size and algorithm for the RCS field, o the size and algorithm for the RCS field,
o the expiration time of the Inactivity Timer o the expiration time of the Inactivity Timer
Each Profile, for each Rule ID value, MAY define Each Profile, for each Rule ID value, MAY define
o a value of N different from the recommended one, o a value of N different from the recommended one,
o the meaning of values sent in the FCN field, for values different o the meaning of values sent in the FCN field, for values different
from the All-1 value. from the All-1 value.
For each active pair of Rule ID and DTag values, the receiver MUST For each active pair of Rule ID and DTag values, the receiver MUST
maintain an Inactivity Timer. maintain an Inactivity Timer. If the receiver is under-resourced to
do this, it MUST silently drop the related messages.
8.4.1.1. Sender behavior 8.4.1.1. Sender behavior
At the beginning of the fragmentation of a new SCHC Packet, the At the beginning of the fragmentation of a new SCHC Packet, the
fragment sender MUST select a Rule ID and DTag value pair for this fragment sender MUST select a Rule ID and DTag value pair for this
SCHC Packet. SCHC Packet.
Each SCHC Fragment MUST contain exactly one tile in its Payload. The Each SCHC Fragment MUST contain exactly one tile in its Payload. The
tile MUST be at least the size of an L2 Word. The sender MUST tile MUST be at least the size of an L2 Word. The sender MUST
transmit the SCHC Fragments messages in the order that the tiles transmit the SCHC Fragments messages in the order that the tiles
skipping to change at page 35, line 28 skipping to change at page 37, line 8
The ACK-Always mode has been designed under the following assumptions The ACK-Always mode has been designed under the following assumptions
o Data unit out-of-sequence delivery does not occur between the o Data unit out-of-sequence delivery does not occur between the
entity performing fragmentation and the entity performing entity performing fragmentation and the entity performing
reassembly reassembly
o The L2 MTU value does not change while the fragments of a SCHC o The L2 MTU value does not change while the fragments of a SCHC
Packet are being transmitted. Packet are being transmitted.
o There is a feedback path from the reassembler to the fragmenter.
See Appendix F for a discussion on using ACK-Always mode on quasi-
bidirectional links.
In ACK-Always mode, windows are used. An acknowledgement, positive In ACK-Always mode, windows are used. An acknowledgement, positive
or negative, is transmitted by the fragment receiver to the fragment or negative, is transmitted by the fragment receiver to the fragment
sender at the end of the transmission of each window of SCHC sender at the end of the transmission of each window of SCHC
Fragments. Fragments.
The tiles are not required to be of uniform size. In ACK-Always The tiles are not required to be of uniform size. In ACK-Always
mode, only the All-1 SCHC Fragment is padded as needed. The other mode, only the All-1 SCHC Fragment is padded as needed. The other
SCHC Fragments are intrinsically aligned to L2 Words. SCHC Fragments are intrinsically aligned to L2 Words.
Briefly, the algorithm is as follows: after a first blind Briefly, the algorithm is as follows: after a first blind
skipping to change at page 36, line 20 skipping to change at page 38, line 4
o the size and algorithm for the RCS field, o the size and algorithm for the RCS field,
o the size of the DTag field, o the size of the DTag field,
o the value of MAX_ACK_REQUESTS, o the value of MAX_ACK_REQUESTS,
o the expiration time of the Retransmission Timer o the expiration time of the Retransmission Timer
o the expiration time of the Inactivity Timer o the expiration time of the Inactivity Timer
For each active pair of Rule ID and DTag values, the sender MUST For each active pair of Rule ID and DTag values, the sender MUST
maintain maintain
o one Attempts counter o one Attempts counter
o one Retransmission Timer o one Retransmission Timer
For each active pair of Rule ID and DTag values, the receiver MUST For each active pair of Rule ID and DTag values, the receiver MUST
maintain an Inactivity Timer. maintain
o one Inactivity Timer
o one Attempts counter
8.4.2.1. Sender behavior 8.4.2.1. Sender behavior
At the beginning of the fragmentation of a new SCHC Packet, the At the beginning of the fragmentation of a new SCHC Packet, the
fragment sender MUST select a Rule ID and DTag value pair for this fragment sender MUST select a Rule ID and DTag value pair for this
SCHC Packet. SCHC Packet.
Each SCHC Fragment MUST contain exactly one tile in its Payload. All Each SCHC Fragment MUST contain exactly one tile in its Payload. All
tiles with the index 0, as well as the last tile, MUST be at least tiles with the index 0, as well as the last tile, MUST be at least
the size of an L2 Word. the size of an L2 Word.
skipping to change at page 37, line 4 skipping to change at page 38, line 39
least significant bit of the window number that the sender is least significant bit of the window number that the sender is
currently processing. currently processing.
For a SCHC Fragment that carries a tile other than the last one of For a SCHC Fragment that carries a tile other than the last one of
the SCHC Packet, the SCHC Packet,
o the Fragment MUST be of the Regular type specified in o the Fragment MUST be of the Regular type specified in
Section 8.3.1.1 Section 8.3.1.1
o the FCN field MUST contain the tile index o the FCN field MUST contain the tile index
o each tile MUST be of a size that complements the SCHC Fragment o each tile MUST be of a size that complements the SCHC Fragment
Header so that the SCHC Fragment is a multiple of L2 Words without Header so that the SCHC Fragment is a multiple of L2 Words without
the need for padding bits. the need for padding bits.
The SCHC Fragment that carries the last tile MUST be an All-1 SCHC The SCHC Fragment that carries the last tile MUST be an All-1 SCHC
Fragment, described in Section 8.3.1.2. Fragment, described in Section 8.3.1.2.
The fragment sender MUST start by transmitting the window numbered 0. The fragment sender MUST start by transmitting the window numbered 0.
All message receptions being discussed in the rest of this section
are to be understood as "matching the RuleID and DTag pair being
processed", even if not spelled out, for brevity.
The sender starts by a "blind transmission" phase, in which it MUST The sender starts by a "blind transmission" phase, in which it MUST
transmit all the tiles composing the window, in decreasing tile index transmit all the tiles composing the window, in decreasing tile index
order. order.
Then, it enters a "retransmission phase" in which it MUST initialize Then, it enters a "retransmission phase" in which it MUST initialize
an Attempts counter to 0, it MUST start a Retransmission Timer and it an Attempts counter to 0, it MUST start a Retransmission Timer and it
MUST await a SCHC ACK. Then, MUST await a SCHC ACK. Then,
o upon receiving a SCHC ACK, o upon receiving a SCHC ACK,
skipping to change at page 38, line 36 skipping to change at page 40, line 27
o the receiver SHOULD check if the DTag value has not recently been o the receiver SHOULD check if the DTag value has not recently been
used for that Rule ID value, thereby ensuring that the received used for that Rule ID value, thereby ensuring that the received
SCHC Fragment is not a remnant of a prior fragmented SCHC Packet SCHC Fragment is not a remnant of a prior fragmented SCHC Packet
transmission. If the SCHC Fragment is determined to be such a transmission. If the SCHC Fragment is determined to be such a
remnant, the receiver MAY silently ignore it and discard it. remnant, the receiver MAY silently ignore it and discard it.
o the receiver MUST start a process to assemble a new SCHC Packet o the receiver MUST start a process to assemble a new SCHC Packet
with that Rule ID and DTag value pair. with that Rule ID and DTag value pair.
o the receiver MUST start an Inactivity Timer. It MUST initialize o the receiver MUST start an Inactivity Timer for that RuleID and
an Attempts counter to 0. It MUST initialize a window counter to DTag pair. It MUST initialize an Attempts counter to 0 for that
0. RuleID and DTag pair. It MUST initialize a window counter to 0.
If the receiver is under-resourced to do this, it MUST respond to
the sender with a SCHC Receiver Abort.
In the rest of this section, "local W bit" means the least In the rest of this section, "local W bit" means the least
significant bit of the window counter of the receiver. significant bit of the window counter of the receiver.
On reception of any SCHC F/R message, the receiver MUST reset the On reception of any SCHC F/R message for the RuleID and DTag pair
Inactivity Timer. being processed, the receiver MUST reset the Inactivity Timer
pertaining to that RuleID and DTag pair.
Entering an "acceptance phase", the receiver MUST first initialize an All message receptions being discussed in the rest of this section
empty Bitmap for this window, then are to be understood as "matching the RuleID and DTag pair being
processed", even if not spelled out, for brevity.
o on receiving a SCHC Fragment or SCHC ACK REQ with the W bit The receiver MUST first initialize an empty Bitmap for the first
different from the local W bit, the receiver MUST silently ignore window, then enter an "acceptance phase", in which
and discard that message.
o on receiving a SCHC Fragment or a SCHC ACK REQ, either one having
the W bit different from the local W bit, the receiver MUST
silently ignore and discard that message.
o on receiving a SCHC ACK REQ with the W bit equal to the local W
bit, the receiver MUST send a SCHC ACK for this window.
o on receiving a SCHC Fragment with the W bit equal to the local W o on receiving a SCHC Fragment with the W bit equal to the local W
bit, the receiver MUST assemble the received tile based on the bit, the receiver MUST assemble the received tile based on the
window counter and on the FCN field in the SCHC Fragment and it window counter and on the FCN field in the SCHC Fragment and it
MUST update the Bitmap. MUST update the Bitmap.
* if the SCHC Fragment received is an All-0 SCHC Fragment, the * if the SCHC Fragment received is an All-0 SCHC Fragment, the
current window is determined to be a not-last window, and the current window is determined to be a not-last window, the
receiver MUST send a SCHC ACK for this window. Then, receiver MUST send a SCHC ACK for this window and it MUST enter
the "retransmission phase" for this window.
+ If the Bitmap indicates that all the tiles of the current
window have been correctly received, the receiver MUST
increment its window counter and it enters the "acceptance
phase" for that new window.
+ If the Bitmap indicates that at least one tile is missing in
the current window, the receiver enters the "retransmission
phase" for this window.
* if the SCHC Fragment received is an All-1 SCHC Fragment, the * if the SCHC Fragment received is an All-1 SCHC Fragment, the
padding bits of the All-1 SCHC Fragment MUST be assembled after padding bits of the All-1 SCHC Fragment MUST be assembled after
the received tile, the current window is determined to be the the received tile, the current window is determined to be the
last window, the receiver MUST perform the integrity check and last window, the receiver MUST perform the integrity check and
it MUST send a SCHC ACK for this window. Then, it MUST send a SCHC ACK for this window. Then,
+ If the integrity check indicates that the full SCHC Packet + If the integrity check indicates that the full SCHC Packet
has been correctly reassembled, the receiver MUST enter the has been correctly reassembled, the receiver MUST enter the
"clean-up phase". "clean-up phase" for this window.
+ If the integrity check indicates that the full SCHC Packet + If the integrity check indicates that the full SCHC Packet
has not been correctly reassembled, the receiver enters the has not been correctly reassembled, the receiver enters the
"retransmission phase" for this window. "retransmission phase" for this window.
o on receiving a SCHC ACK REQ with the W bit equal to the local W
bit, the receiver has not yet determined if the current window is
a not-last one or the last one, the receiver MUST send a SCHC ACK
for this window, and it keeps accepting incoming messages.
In the "retransmission phase": In the "retransmission phase":
o if the window is a not-last window o if the window is a not-last window
* on receiving a SCHC Fragment or SCHC ACK REQ with a W bit * on receiving a SCHC Fragment that is not All-0 or All-1 and
different from the local W bit the receiver MUST silently that has a W bit different from the local W bit, the receiver
ignore and discard that message. MUST increment its window counter and allocate a fresh Bitmap,
it MUST assemble the tile received and update the Bitmap and it
MUST enter the "acceptance phase" for that new window.
* on receiving a SCHC ACK REQ with a W bit equal to the local W * on receiving a SCHC ACK REQ with a W bit different from the
bit, the receiver MUST send a SCHC ACK for this window. local W bit, the receiver MUST increment its window counter and
allocate a fresh Bitmap, it MUST send a SCHC ACK for that new
window and it MUST enter the "acceptance phase" for that new
window.
* on receiving a SCHC All-0 Fragment with a W bit different from
the local W bit, the receiver MUST increment its window counter
and allocate a fresh Bitmap, it MUST assemble the tile received
and update the Bitmap, it MUST send a SCHC ACK for that new
window and it MUST stay in the "retransmission phase" for that
new window.
* on receiving a SCHC All-1 Fragment with a W bit different from
the local W bit, the receiver MUST increment its window counter
and allocate a fresh Bitmap, it MUST assemble the tile
received, including the padding bits, it MUST update the Bitmap
and perform the integrity check, it MUST send a SCHC ACK for
the new window, which is determined to be the last window.
Then,
+ If the integrity check indicates that the full SCHC Packet
has been correctly reassembled, the receiver MUST enter the
"clean-up phase" for that new window.
+ If the integrity check indicates that the full SCHC Packet
has not been correctly reassembled, the receiver enters the
"retransmission phase" for that new window.
* on receiving a SCHC Fragment with a W bit equal to the local W * on receiving a SCHC Fragment with a W bit equal to the local W
bit, bit,
+ if the SCHC Fragment received is an All-1 SCHC Fragment, the + if the SCHC Fragment received is an All-1 SCHC Fragment, the
receiver MUST silently ignore it and discard it. receiver MUST silently ignore it and discard it.
+ otherwise, the receiver MUST update the Bitmap and it MUST + otherwise, the receiver MUST assemble the tile received and
assemble the tile received. update the Bitmap. If the Bitmap becomes fully populated
with 1's or if the SCHC Fragment is an All-0, the receiver
MUST send a SCHC ACK for this window.
* on the Bitmap becoming fully populated with 1's, the receiver * on receiving a SCHC ACK REQ with the W bit equal to the local W
MUST send a SCHC ACK for this window, it MUST increment its bit, the receiver MUST send a SCHC ACK for this window.
window counter and it enters the "acceptance phase" for the new
window.
o if the window is the last window o if the window is the last window
* on receiving a SCHC Fragment or SCHC ACK REQ with a W bit * on receiving a SCHC Fragment or a SCHC ACK, either one having a
different from the local W bit the receiver MUST silently W bit different from the local W bit, the receiver MUST
ignore and discard that message. silently ignore and discard that message.
* on receiving a SCHC ACK REQ with a W bit equal to the local W * on receiving a SCHC ACK REQ with the W bit equal to the local W
bit, the receiver MUST send a SCHC ACK for this window. bit, the receiver MUST send a SCHC ACK for this window.
* on receiving a SCHC Fragment with a W bit equal to the local W * on receiving a SCHC Fragment with a W bit equal to the local W
bit, bit,
+ if the SCHC Fragment received is an All-0 SCHC Fragment, the + if the SCHC Fragment received is an All-0 SCHC Fragment, the
receiver MUST silently ignore it and discard it. receiver MUST silently ignore it and discard it.
+ otherwise, the receiver MUST update the Bitmap and it MUST + otherwise, the receiver MUST update the Bitmap and it MUST
assemble the tile received. If the SCHC Fragment received assemble the tile received. If the SCHC Fragment received
is an All-1 SCHC Fragment, the receiver MUST assemble the is an All-1 SCHC Fragment, the receiver MUST assemble the
padding bits of the All-1 SCHC Fragment after the received padding bits of the All-1 SCHC Fragment after the received
tile. It MUST perform the integrity check. Then tile, it MUST perform the integrity check and
- if the integrity check indicates that the full SCHC - if the integrity check indicates that the full SCHC
Packet has been correctly reassembled, the receiver MUST Packet has been correctly reassembled, the receiver MUST
send a SCHC ACK and it enters the "clean-up phase". send a SCHC ACK and it enters the "clean-up phase".
- if the integrity check indicates that the full SCHC - if the integrity check indicates that the full SCHC
Packet has not been correctly reassembled, Packet has not been correctly reassembled,
o if the SCHC Fragment received was an All-1 SCHC o if the SCHC Fragment received was an All-1 SCHC
Fragment, the receiver MUST send a SCHC ACK for this Fragment, the receiver MUST send a SCHC ACK for this
window window.
o it keeps accepting incoming messages.
In the "clean-up phase": In the "clean-up phase":
o Any received SCHC F/R message with a W bit different from the o On receiving an All-1 SCHC Fragment or a SCHC ACK REQ, either one
local W bit MUST be silently ignored and discarded. having the W bit equal to the local W bit, the receiver MUST send
a SCHC ACK.
o Any received SCHC F/R message different from an All-1 SCHC
Fragment or a SCHC ACK REQ MUST be silently ignored and discarded.
o On receiving an All-1 SCHC Fragment or a SCHC ACK REQ, the o Any other SCHC Fragment received MUST be silently ignored and
receiver MUST send a SCHC ACK. discarded.
At any time, on expiration of the Inactivity Timer, on receiving a At any time, on expiration of the Inactivity Timer, on receiving a
SCHC Sender-Abort or when Attempts reaches MAX_ACK_REQUESTS, the SCHC Sender-Abort or when Attempts reaches MAX_ACK_REQUESTS, the
receiver MUST send a SCHC Receiver-Abort and it MAY exit the receive receiver MUST send a SCHC Receiver-Abort and it MAY exit the receive
process for that SCHC Packet. process for that SCHC Packet.
Figure 40 shows an example of a corresponding state machine. Figure 40 shows an example of a corresponding state machine.
8.4.3. ACK-on-Error mode 8.4.3. ACK-on-Error mode
The ACK-on-Error mode supports LPWAN technologies that have variable The ACK-on-Error mode supports LPWAN technologies that have variable
MTU and out-of-order delivery. MTU and out-of-order delivery. It operates with links that provide a
feedback path from the reassembler to the fragmenter. See Appendix F
for a discussion on using ACK-on-Error mode on quasi-bidirectional
links.
In ACK-on-Error mode, windows are used. All tiles MUST be of equal In ACK-on-Error mode, windows are used.
size, except for the last one, which MUST be of the same size or
smaller than the regular ones. If allowed in a Profile, the
penultimate tile MAY be exactly one L2 Word smaller than the regular
tile size.
A SCHC Fragment message carries one or more tiles, which may span All tiles, but the last one and the penultimate one, MUST be of equal
multiple windows. A SCHC ACK reports on the reception of exactly one size, hereafter called "regular". The size of the last tile MUST be
window of tiles. smaller than or equal to the regular tile size. Regarding the
penultimate tile, a Profile MUST pick one of the following two
options:
o The penultimate tile size MUST be the regular tile size
o or the penultimate tile size MUST be either the regular tile size
or the regular tile size minus one L2 Word.
A SCHC Fragment message carries one or several contiguous tiles,
which may span multiple windows. A SCHC ACK reports on the reception
of exactly one window of tiles.
See Figure 23 for an example. See Figure 23 for an example.
+---------------------------------------------...-----------+ +---------------------------------------------...-----------+
| SCHC Packet | | SCHC Packet |
+---------------------------------------------...-----------+ +---------------------------------------------...-----------+
Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3| Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3|
Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-| Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-|
SCHC Fragment msg |-----------| SCHC Fragment msg |-----------|
Figure 23: a SCHC Packet fragmented in tiles, Ack-on-Error mode Figure 23: a SCHC Packet fragmented in tiles, ACK-on-Error mode
The W field is wide enough that it unambiguously represents an The W field is wide enough that it unambiguously represents an
absolute window number. The fragment receiver sends SCHC ACKs to the absolute window number. The fragment receiver sends SCHC ACKs to the
fragment sender about windows for which tiles are missing. No SCHC fragment sender about windows for which tiles are missing. No SCHC
ACK is sent by the fragment receiver for windows that it knows have ACK is sent by the fragment receiver for windows that it knows have
been fully received. been fully received.
The fragment sender retransmits SCHC Fragments for tiles that are The fragment sender retransmits SCHC Fragments for tiles that are
reported missing. It can advance to next windows even before it has reported missing. It can advance to next windows even before it has
ascertained that all tiles belonging to previous windows have been ascertained that all tiles belonging to previous windows have been
skipping to change at page 43, line 4 skipping to change at page 45, line 27
o the size and algorithm for the RCS field, o the size and algorithm for the RCS field,
o the size of the DTag field, o the size of the DTag field,
o the value of MAX_ACK_REQUESTS, o the value of MAX_ACK_REQUESTS,
o the expiration time of the Retransmission Timer o the expiration time of the Retransmission Timer
o the expiration time of the Inactivity Timer o the expiration time of the Inactivity Timer
o if the last tile is carried in a Regular SCHC Fragment or an All-1 o if the last tile is carried in a Regular SCHC Fragment or an All-1
SCHC Fragment (see Section 8.4.3.1) SCHC Fragment (see Section 8.4.3.1)
o if the penultimate tile MAY be one L2 Word smaller than the o if the penultimate tile MAY be one L2 Word smaller than the
regular tile size. In this case, the regular tile size MUST be at regular tile size. In this case, the regular tile size MUST be at
least twice the L2 Word size. least twice the L2 Word size.
For each active pair of Rule ID and DTag values, the sender MUST For each active pair of Rule ID and DTag values, the sender MUST
maintain maintain
o one Attempts counter o one Attempts counter
o one Retransmission Timer o one Retransmission Timer
For each active pair of Rule ID and DTag values, the receiver MUST For each active pair of Rule ID and DTag values, the receiver MUST
maintain an Inactivity Timer. maintain
o one Inactivity Timer
o one Attempts counter
8.4.3.1. Sender behavior 8.4.3.1. Sender behavior
At the beginning of the fragmentation of a new SCHC Packet, At the beginning of the fragmentation of a new SCHC Packet,
o the fragment sender MUST select a Rule ID and DTag value pair for o the fragment sender MUST select a Rule ID and DTag value pair for
this SCHC Packet. A Rule MUST NOT be selected if the values of M this SCHC Packet. A Rule MUST NOT be selected if the values of M
and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot
be fragmented in (2^M) * WINDOW_SIZE tiles or less. be fragmented in (2^M) * WINDOW_SIZE tiles or less.
o the fragment sender MUST initialize the Attempts counter to 0 for o the fragment sender MUST initialize the Attempts counter to 0 for
that Rule ID and DTag value pair. that Rule ID and DTag value pair.
A Regular SCHC Fragment message carries in its payload one or more A Regular SCHC Fragment message carries in its payload one or more
tiles. If more than one tile is carried in one Regular SCHC Fragment tiles. If more than one tile is carried in one Regular SCHC Fragment
o the selected tiles MUST be consecutive in the original SCHC Packet o the selected tiles MUST be contiguous in the original SCHC Packet
o they MUST be placed in the SCHC Fragment Payload adjacent to one o they MUST be placed in the SCHC Fragment Payload adjacent to one
another, in the order they appear in the SCHC Packet, from the another, in the order they appear in the SCHC Packet, from the
start of the SCHC Packet toward its end. start of the SCHC Packet toward its end.
Tiles that are not the last one MUST be sent in Regular SCHC Tiles that are not the last one MUST be sent in Regular SCHC
Fragments specified in Section 8.3.1.1. The FCN field MUST contain Fragments specified in Section 8.3.1.1. The FCN field MUST contain
the tile index of the first tile sent in that SCHC Fragment. the tile index of the first tile sent in that SCHC Fragment.
In a Regular SCHC Fragment message, the sender MUST fill the W field In a Regular SCHC Fragment message, the sender MUST fill the W field
skipping to change at page 44, line 44 skipping to change at page 47, line 26
On Retransmission Timer expiration On Retransmission Timer expiration
o if Attempts is strictly less than MAX_ACK_REQUESTS, the fragment o if Attempts is strictly less than MAX_ACK_REQUESTS, the fragment
sender MUST send either the All-1 SCHC Fragment or a SCHC ACK REQ sender MUST send either the All-1 SCHC Fragment or a SCHC ACK REQ
with the W field corresponding to the last window, with the W field corresponding to the last window,
o otherwise the fragment sender MUST send a SCHC Sender-Abort and it o otherwise the fragment sender MUST send a SCHC Sender-Abort and it
MAY exit with an error condition. MAY exit with an error condition.
All message receptions being discussed in the rest of this section
are to be understood as "matching the RuleID and DTag pair being
processed", even if not spelled out, for brevity.
On receiving a SCHC ACK, On receiving a SCHC ACK,
o if the W field in the SCHC ACK corresponds to the last window of o if the W field in the SCHC ACK corresponds to the last window of
the SCHC Packet, the SCHC Packet,
* if the C bit is set, the sender MAY exit successfully * if the C bit is set, the sender MAY exit successfully
* otherwise, * otherwise,
+ if the Profile mandates that the last tile be sent in an + if the Profile mandates that the last tile be sent in an
All-1 SCHC Fragment, All-1 SCHC Fragment,
- if the SCHC ACK shows no missing tile at the receiver, - if the SCHC ACK shows no missing tile at the receiver,
the sender the sender
o MUST send a SCHC Sender-Abort o MUST send a SCHC Sender-Abort
o MAY exit with an error condition o MAY exit with an error condition
skipping to change at page 46, line 17 skipping to change at page 49, line 6
On receiving a SCHC Fragment with a Rule ID and DTag pair not being On receiving a SCHC Fragment with a Rule ID and DTag pair not being
processed at that time processed at that time
o the receiver SHOULD check if the DTag value has not recently been o the receiver SHOULD check if the DTag value has not recently been
used for that Rule ID value, thereby ensuring that the received used for that Rule ID value, thereby ensuring that the received
SCHC Fragment is not a remnant of a prior fragmented SCHC Packet SCHC Fragment is not a remnant of a prior fragmented SCHC Packet
transmission. If the SCHC Fragment is determined to be such a transmission. If the SCHC Fragment is determined to be such a
remnant, the receiver MAY silently ignore it and discard it. remnant, the receiver MAY silently ignore it and discard it.
o the receiver MUST start a process to assemble a new SCHC Packet o the receiver MUST start a process to assemble a new SCHC Packet
with that Rule ID and DTag value pair. with that Rule ID and DTag value pair. The receiver MUST start an
Inactivity Timer for that Rule ID and DTag value pair. It MUST
initialize an Attempts counter to 0 for that Rule ID and DTag
value pair. If the receiver is under-resourced to do this, it
MUST respond to the sender with a SCHC Receiver Abort.
o the receiver MUST start an Inactivity Timer. It MUST initialize On reception of any SCHC F/R message for the RuleID and DTag pair
an Attempts counter to 0. being processed, the receiver MUST reset the Inactivity Timer
pertaining to that RuleID and DTag pair.
On receiving any SCHC F/R message, the receiver MUST reset the All message receptions being discussed in the rest of this section
Inactivity Timer. are to be understood as "matching the RuleID and DTag pair being
processed", even if not spelled out, for brevity.
On receiving a SCHC Fragment message, the receiver determines what On receiving a SCHC Fragment message, the receiver determines what
tiles were received, based on the payload length and on the W and FCN tiles were received, based on the payload length and on the W and FCN
fields of the SCHC Fragment. fields of the SCHC Fragment.
o if the FCN is All-1, if a Payload is present, the full SCHC o if the FCN is All-1, if a Payload is present, the full SCHC
Fragment Payload MUST be assembled including the padding bits. Fragment Payload MUST be assembled including the padding bits.
This is because the size of the last tile is not known by the This is because the size of the last tile is not known by the
receiver, therefore padding bits are indistinguishable from the receiver, therefore padding bits are indistinguishable from the
tile data bits, at this stage. They will be removed by the SCHC tile data bits, at this stage. They will be removed by the SCHC
skipping to change at page 49, line 21 skipping to change at page 51, line 40
| ^ | ^
| If no fragmentation | | If no fragmentation |
+---- SCHC Packet + padding as needed ----->| +---- SCHC Packet + padding as needed ----->|
| | (integrity | | (integrity
v | checked) v | checked)
+--------------------+ +-----------------+ +--------------------+ +-----------------+
| SCHC Fragmentation | | SCHC Reassembly | | SCHC Fragmentation | | SCHC Reassembly |
+--------------------+ +-----------------+ +--------------------+ +-----------------+
| ^ | ^ | ^ | ^
| | | | | | | |
| +------------- SCHC ACK ------------+ | | +--- SCHC ACK + padding as needed --+ |
| | | |
+------- SCHC Fragments + padding as needed---------+ +------- SCHC Fragments + padding as needed---------+
Sender Receiver Sender Receiver
Figure 24: SCHC operations, including padding as needed Figure 24: SCHC operations, including padding as needed
Each Profile MUST specify the size of the L2 Word. The L2 Word might Each Profile MUST specify the size of the L2 Word. The L2 Word might
actually be a single bit, in which case no padding will take place at actually be a single bit, in which case no padding will take place at
all. all.
A Profile MAY define the value of the padding bits. The RECOMMENDED A Profile MAY define the value of the padding bits. The RECOMMENDED
value is 0. value is 0.
10. SCHC Compression for IPv6 and UDP headers 10. SCHC Compression for IPv6 and UDP headers
This section lists the IPv6 and UDP header fields and describes how This section lists the IPv6 and UDP header fields and describes how
they can be compressed. they can be compressed. An example of a set of Rules for UDP/IPv6
header compression is provided in Appendix A.
10.1. IPv6 version field 10.1. IPv6 version field
The IPv6 version field is labeled by the protocol parser as being the The IPv6 version field is labeled by the protocol parser as being the
"version" field of the IPv6 protocol. Therefore, it only exists for "version" field of the IPv6 protocol. Therefore, it only exists for
IPv6 packets. In the Rule, TV is set to 6, MO to "ignore" and CDA to IPv6 packets. In the Rule, TV is set to 6, MO to "ignore" and CDA to
"not-sent". "not-sent".
10.2. IPv6 Traffic class field 10.2. IPv6 Traffic class field
skipping to change at page 50, line 23 skipping to change at page 52, line 39
o One possibility is to not compress the field and send the original o One possibility is to not compress the field and send the original
value. In the Rule, TV is not set to any particular value, MO is value. In the Rule, TV is not set to any particular value, MO is
set to "ignore" and CDA is set to "value-sent". set to "ignore" and CDA is set to "value-sent".
o If some upper bits in the field are constant and known, a better o If some upper bits in the field are constant and known, a better
option is to only send the LSBs. In the Rule, TV is set to a option is to only send the LSBs. In the Rule, TV is set to a
value with the stable known upper part, MO is set to MSB(x) and value with the stable known upper part, MO is set to MSB(x) and
CDA to LSB. CDA to LSB.
10.3. Flow label field ECN functionality depends on both bits of the ECN field, which are
the 2 LSBs of this field, hence sending only a single LSB of this
If the Flow Label field does not vary and is known by both sides, the field is NOT RECOMMENDED.
Field Descriptor in the Rule SHOULD contain a TV with this well-known
value, an "equal" MO and a "not-sent" CDA.
Otherwise, two possibilities can be considered: 10.3. Flow label field
o One possibility is to not compress the field and send the original If the flow label is not set, i.e. its value is zero, the Field
value. In the Rule, TV is not set to any particular value, MO is Descriptor in the Rule SHOULD contain a TV set to zero, an "equal" MO
set to "ignore" and CDA is set to "value-sent". and a "not-sent" CDA.
o If some upper bits in the field are constant and known, a better If the flow label is set to a pseudo-random value according to
option is to only send the LSBs. In the Rule, TV is set to a [RFC6437], in the Rule, TV is not set to any particular value, MO is
value with the stable known upper part, MO is set to MSB(x) and set to "ignore" and CDA is set to "value-sent".
CDA to LSB.
ECN functionality depends on both bits of the ECN field, which are If the flow label is set according to some prior agreement, i.e. by a
the 2 LSBs of this field, hence sending only a single LSB of this flow state establishment method as allowed by [RFC6437], the Field
field is NOT RECOMMENDED. Descriptor in the Rule SHOULD contain a TV with this agreed-upon
value, an "equal" MO and a "not-sent" CDA.
10.4. Payload Length field 10.4. Payload Length field
This field can be elided for the transmission on the LPWAN network. This field can be elided for the transmission on the LPWAN network.
The SCHC C/D recomputes the original payload length value. In the The SCHC C/D recomputes the original payload length value. In the
Field Descriptor, TV is not set, MO is set to "ignore" and CDA is Field Descriptor, TV is not set, MO is set to "ignore" and CDA is
"compute-*". "compute-*".
10.5. Next Header field 10.5. Next Header field
skipping to change at page 52, line 23 skipping to change at page 54, line 34
be reconstructed with information coming from the LPWAN header. In be reconstructed with information coming from the LPWAN header. In
that case, the TV is not set, the MO is set to "ignore" and the CDA that case, the TV is not set, the MO is set to "ignore" and the CDA
is set to "DevIID" or "AppIID". On LPWAN technologies where the is set to "DevIID" or "AppIID". On LPWAN technologies where the
frames carry a single identifier (corresponding to the Dev.), AppIID frames carry a single identifier (corresponding to the Dev.), AppIID
cannot be used. cannot be used.
As described in [RFC8065], it may be undesirable to build the Dev As described in [RFC8065], it may be undesirable to build the Dev
IPv6 IID out of the Dev address. Another static value is used IPv6 IID out of the Dev address. Another static value is used
instead. In that case, the TV contains the static value, the MO instead. In that case, the TV contains the static value, the MO
operator is set to "equal" and the CDA is set to "not-sent". operator is set to "equal" and the CDA is set to "not-sent".
[RFC7217] provides some methods to derive this static identifier.
If several IIDs are possible, then the TV contains the list of If several IIDs are possible, then the TV contains the list of
possible IIDs, the MO is set to "match-mapping" and the CDA is set to possible IIDs, the MO is set to "match-mapping" and the CDA is set to
"mapping-sent". "mapping-sent".
It may also happen that the IID variability only expresses itself on It may also happen that the IID variability only expresses itself on
a few bytes. In that case, the TV is set to the stable part of the a few bytes. In that case, the TV is set to the stable part of the
IID, the MO is set to "MSB" and the CDA is set to "LSB". IID, the MO is set to "MSB" and the CDA is set to "LSB".
Finally, the IID can be sent in its entirety on the LPWAN. In that Finally, the IID can be sent in its entirety on the LPWAN. In that
case, the TV is not set, the MO is set to "ignore" and the CDA is set case, the TV is not set, the MO is set to "ignore" and the CDA is set
to "value-sent". to "value-sent".
10.8. IPv6 extensions 10.8. IPv6 extension headers
This document does not provide recommendations on how to compress This document does not provide recommendations on how to compress
IPv6 extensions. IPv6 extension headers.
10.9. UDP source and destination port 10.9. UDP source and destination ports
To allow for a single Rule being used for both directions, the UDP To allow for a single Rule being used for both directions, the UDP
port values are identified by their role (Dev or App) and not by port values are identified by their role (Dev or App) and not by
their position in the header (source or destination). The SCHC C/D their position in the header (source or destination). The SCHC C/D
MUST be aware of the traffic direction (Uplink, Downlink) to select MUST be aware of the traffic direction (Uplink, Downlink) to select
the appropriate field. The following Rules apply for Dev and App the appropriate field. The following Rules apply for Dev and App
port numbers. port numbers.
If both ends know the port number, it can be elided. The TV contains If both ends know the port number, it can be elided. The TV contains
the port number, the MO is set to "equal" and the CDA is set to "not- the port number, the MO is set to "equal" and the CDA is set to "not-
skipping to change at page 54, line 26 skipping to change at page 56, line 36
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 CDA is set to "value- not set, the MO is set to "ignore" and the CDA is set to "value-
sent". sent".
11. IANA Considerations 11. IANA Considerations
This document has no request to IANA. This document has no request to IANA.
12. Security considerations 12. Security considerations
Wireless networks are subjects to various sorts of attacks, which are As explained in Section 5, SCHC is expected to be implemented on top
not specific to SCHC. In this section, we'll assume that an attacker of LPWAN technologies, which are expected to implement security
was able to break into the network despite the latter's security measures.
measures and that it can now send packets to a target node. What is
specific to SCHC is the amplification of the effects that this break- In this section, we analyze the potential security threats that could
in could allow. Our analysis equally applies to legitimate nodes be introduced into an LPWAN by adding the SCHC functionalities.
"going crazy".
12.1. Security considerations for SCHC Compression/Decompression 12.1. Security considerations for SCHC Compression/Decompression
12.1.1. Forged SCHC Packet
Let's assume that an attacker is able to send a forged SCHC Packet to Let's assume that an attacker is able to send a forged SCHC Packet to
a SCHC Decompressor. a SCHC Decompressor.
Let's first consider the case where the Rule ID contained in that Let's first consider the case where the Rule ID contained in that
forged SCHC Packet does not correspond to a Rule allocated in the forged SCHC Packet does not correspond to a Rule allocated in the
Rule table. An implementation should detect that the Rule ID is Rule table. An implementation should detect that the Rule ID is
invalid and should silently drop the offending SCHC Packet. invalid and should silently drop the offending SCHC Packet.
Let's now consider that the Rule ID corresponds to a Rule in the Let's now consider that the Rule ID corresponds to a Rule in the
table. With the CDAs defined in this document, the reconstructed table. With the CDAs defined in this document, the reconstructed
skipping to change at page 55, line 13 skipping to change at page 57, line 24
recommended by this document. recommended by this document.
As a consequence, SCHC Decompression does not amplify attacks, beyond As a consequence, SCHC Decompression does not amplify attacks, beyond
adding a bounded number of bits to the SCHC Packet received. This adding a bounded number of bits to the SCHC Packet received. This
bound is determined by the Rule stored in the receiving device. bound is determined by the Rule stored in the receiving device.
As a general safety measure, a SCHC Decompressor should never re- As a general safety measure, a SCHC Decompressor should never re-
construct a packet larger than MAX_PACKET_SIZE (defined in a Profile, construct a packet larger than MAX_PACKET_SIZE (defined in a Profile,
with 1500 bytes as generic default). with 1500 bytes as generic default).
12.1.2. Compressed packet size as a side channel to guess a secret
token
Some packet compression methods are known to be victims of attacks,
such as BREACH and CRIME. The attack involves injecting arbitrary
data into the packet and observing the resulting compresssed packet
size. The observed size potentially reflects correlation between the
arbitrary data and some content that was meant to remain secret, such
as a security token, thereby allowing the attacker to get at the
secret.
By contrast, SCHC Compression takes place header field by header
field, with the SCHC Packet being a mere concatenation of the
compression residues of each of the individual field. Any
correlation between header fields does not result in a change in the
SCHC Packet size compressed under the same Rule.
If SCHC C/D is used to compress packets that include a secret
information field, such as a token, the Rule set should be designed
so that the size of the compression residue for the field to remain
secret is the same irrespective of the value of the secret
information. This is achieved by e.g. sending this field in extenso
with the "ignore" MO and the "value-sent" CDA. This recommendation
is disputable if it is ascertained that the Rule set itself will
remain secret.
12.1.3. decompressed packet different from the original packet
The attention of Rule designers is drawn to situation As explained in
Section 7.3, using FPs with value 0 in Field Descriptors in a Rule
may result in header fields appearing in the decompressed packet in
an order different from that in the original packet. Likewise, as
stated in Section 7.5.3, using an "ignore" MO together with a "not-
sent" CDA will result in the header field taking the TV value, which
is likely to be different from the original value.
Depending on the protocol, the order of header fields in the packet
may be functionally significant or not.
Furthermore, if the packet is protected by a checksum or a similar
integrity protection mechanism, and if the checksum is transmitted
instead of being recomputed as part of the decompression, these
situations may result in the packet being considered corrupt and
dropped.
12.2. Security considerations for SCHC Fragmentation/Reassembly 12.2. Security considerations for SCHC Fragmentation/Reassembly
Let's assume that an attacker is able to send to a forged SCHC 12.2.1. Buffer reservation attack
Fragment to a SCHC Reassembler.
Let's assume that an attacker is able to send a forged SCHC Fragment
to a SCHC Reassembler.
A node can perform a buffer reservation attack: the receiver will A node can perform a buffer reservation attack: the receiver will
reserve buffer space for the SCHC Packet. If the implementation has reserve buffer space for the SCHC Packet. If the implementation has
only one buffer, other incoming fragmented SCHC Packets will be only one buffer, other incoming fragmented SCHC Packets will be
dropped while the reassembly buffer is occupied during the reassembly dropped while the reassembly buffer is occupied during the reassembly
timeout. Once that timeout expires, the attacker can repeat the same timeout. Once that timeout expires, the attacker can repeat the same
procedure, and iterate, thus creating a denial of service attack. An procedure, and iterate, thus creating a denial of service attack. An
implementation may have multiple reassembly buffers. The cost to implementation may have multiple reassembly buffers. The cost to
mount this attack is linear with the number of buffers at the target mount this attack is linear with the number of buffers at the target
node. Better, the cost for an attacker can be increased if node. Better, the cost for an attacker can be increased if
skipping to change at page 55, line 39 skipping to change at page 59, line 5
the smallest tile size), the higher the cost of the attack. If the smallest tile size), the higher the cost of the attack. If
buffer overload does occur, a smart receiver could selectively buffer overload does occur, a smart receiver could selectively
discard SCHC Packets being reassembled based on the sender behavior, discard SCHC Packets being reassembled based on the sender behavior,
which may help identify which SCHC Fragments have been sent by the which may help identify which SCHC Fragments have been sent by the
attacker. Another mild counter-measure is for the target to abort attacker. Another mild counter-measure is for the target to abort
the fragmentation/reassembly session as early as it detects a non- the fragmentation/reassembly session as early as it detects a non-
identical SCHC Fragment duplicate, anticipating for an eventual identical SCHC Fragment duplicate, anticipating for an eventual
corrupt SCHC Packet, so as to save the sender the hassle of sending corrupt SCHC Packet, so as to save the sender the hassle of sending
the rest of the fragments for this SCHC Packet. the rest of the fragments for this SCHC Packet.
In another type of attack, the malicious node is additionally assumed 12.2.2. Corrupt Fragment attack
to be able to hear an incoming communication destined to the target
node. It can then send a forged SCHC Fragment that looks like it Let's assume that an attacker is able to send a forged SCHC Fragment
belongs to a SCHC Packet already being reassembled at the target to a SCHC Reassembler. The malicious node is additionally assumed to
node. This can cause the SCHC Packet to be considered corrupt and be be able to hear an incoming communication destined to the target
dropped by the receiver. The amplification happens here by a single node.
spoofed SCHC Fragment rendering a full sequence of legit SCHC
Fragments useless. If the target uses ACK-Always or ACK-on-Error It can then send a forged SCHC Fragment that looks like it belongs to
mode, such a malicious node can also interfere with the a SCHC Packet already being reassembled at the target node. This can
acknowledgement and repetition algorithm of SCHC F/R. A single cause the SCHC Packet to be considered corrupt and be dropped by the
spoofed ACK, with all bitmap bits set to 0, will trigger the receiver. The amplification happens here by a single spoofed SCHC
repetition of WINDOW_SIZE tiles. This protocol loop amplification Fragment rendering a full sequence of legit SCHC Fragments useless.
depletes the energy source of the target node and consumes the If the target uses ACK-Always or ACK-on-Error mode, such a malicious
channel bandwidth. Similarly, a spoofed ACK REQ will trigger the node can also interfere with the acknowledgement and repetition
sending of a SCHC ACK, which may be much larger than the ACK REQ if algorithm of SCHC F/R. A single spoofed ACK, with all bitmap bits
WINDOW_SIZE is large. These consequences should be borne in mind set to 0, will trigger the repetition of WINDOW_SIZE tiles. This
when defining profiles for SCHC over specific LPWAN technologies. protocol loop amplification depletes the energy source of the target
node and consumes the channel bandwidth. Similarly, a spoofed ACK
REQ will trigger the sending of a SCHC ACK, which may be much larger
than the ACK REQ if WINDOW_SIZE is large. These consequences should
be borne in mind when defining profiles for SCHC over specific LPWAN
technologies.
12.2.3. Fragmentation as a way to bypass Network Inspection
Fragmentation is known for potentially allowing to force through a
Network Inspection device (e.g. firewall) packets that would be
rejected if unfragmented. This involves sending overlapping
fragments to rewrite fields whose initial value led the Network
Inspection device to allow the flow go through.
SCHC F/R is expected to be used over one LPWAN link, where no Network
Inspection device is expected to sit. As described in Section 5.2,
even if the SCHC F/R on the Network infrastructure side is located in
the Internet, a tunnel is to be established between it and the NGW.
12.2.4. Privacy issues associated with SCHC header fields
SCHC F/R allocates a DTag value to fragments belonging to the same
SCHC Packet. Concerns were raised that, if DTag is a wide counter
that is incremented in a predictible fashion for each new fragmented
SCHC Packet, it might lead to a privacy issue, such as enabling
tracking of a device across LPWANs.
However, SCHC F/R is expected to be used over exactly one LPWAN link.
As described in Section 5.2, even if the SCHC F/R on the Network
infrastructure side is located in the Internet, a tunnel is to be
established between it and the NGW. Therefore, neither the DTag
field nor any other SCHC-introduced field is visible over the
Internet.
13. Acknowledgements 13. Acknowledgements
Thanks to Sergio Aguilar Romero, Carsten Bormann, David Black, Thanks to Sergio Aguilar Romero, Brian Carpenter, Carsten Bormann,
Philippe Clavier, Daniel Ducuara Beltran Diego Dujovne, Eduardo David Black, Deborah Brungard, Philippe Clavier, Alissa Cooper, Roman
Ingles Sanchez, Arunprabhu Kandasamy, Suresh Krishnan, Rahul Jadhav, Danyliw, Daniel Ducuara Beltran, Diego Dujovne, Eduardo Ingles
Sergio Lopez Bernal, Antony Markovski, Alexander Pelov, Charles Sanchez, Benjamin Kaduk, Arunprabhu Kandasamy, Suresh Krishnan, Mirja
Perkins, Edgar Ramos, Shoichi Sakane, and Pascal Thubert for useful Kuehlewind, Rahul Jadhav, Barry Leiba, Sergio Lopez Bernal, Antony
design consideration and comments. Markovski, Alexey Melnikov, Alexander Pelov, Charles Perkins, Edgar
Ramos, Alvaro Retana, Adam Roach, Shoichi Sakane, Joseph Salowey,
Pascal Thubert, and Eric Vyncke for useful design considerations,
reviews and comments.
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.
14. References 14. References
skipping to change at page 56, line 47 skipping to change at page 60, line 49
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.
14.2. Informative References 14.2. Informative References
[RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, [ETHERNET]
"Internet Protocol Small Computer System Interface (iSCSI) "IEEE Standard for Ethernet", IEEE standard,
Cyclic Redundancy Check (CRC)/Checksum Considerations", DOI 10.1109/ieeestd.2018.8457469, n.d..
RFC 3385, DOI 10.17487/RFC3385, September 2002,
<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>.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795, Header Compression (ROHC) Framework", RFC 5795,
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>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[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>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <https://www.rfc-editor.org/info/rfc8065>. February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.
Appendix A. Compression Examples Appendix A. Compression Examples
This section gives some scenarios of the compression mechanism for This section gives some scenarios of the compression mechanism for
IPv6/UDP. The goal is to illustrate the behavior of SCHC. IPv6/UDP. The goal is to illustrate the behavior of SCHC.
The mechanisms defined in this document can be applied to a Dev that The mechanisms defined in this document can be applied to a Dev that
embeds some applications running over CoAP. In this example, three embeds some applications running over CoAP. In this example, three
flows are considered. The first flow is for the device management flows are considered. The first flow is for the device management
based on CoAP using Link Local IPv6 addresses and UDP ports 123 and based on CoAP using Link Local IPv6 addresses and UDP ports 123 and
124 for Dev and App, respectively. The second flow will be a CoAP 124 for Dev and App, respectively. The second flow will be a CoAP
skipping to change at page 71, line 6 skipping to change at page 74, line 6
| send lcl_bm | | | ~~~~~~~~~ | | send lcl_bm | | | ~~~~~~~~~ |
| | | | discard | | | | | discard |
|All-1&w=expected & RCS right | | | | |All-1&w=expected & RCS right | | | |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 |
|set lcl_bm(FCN) +=+=+=+=+==+ |~~~~~~~~~ | |set lcl_bm(FCN) +=+=+=+=+==+ |~~~~~~~~~ |
|send lcl_bm | +<+Send lcl_bm | |send lcl_bm | +<+Send lcl_bm |
+-------------------------->+ END | | +-------------------------->+ END | |
+==========+<---------------+ +==========+<---------------+
--->* ABORT --->* ABORT
~~~~~~~
Inactivity_Timer = expires In any state
When DWL on receiving a SCHC ACK REQ
IF Inactivity_Timer expires Send a SCHC ACK for the current window
Send DWL Request
Attempt++
Figure 40: Receiver State Machine for the ACK-Always Mode Figure 40: Receiver State Machine for the ACK-Always Mode
+=======+ +=======+
| | | |
| INIT | | INIT |
| | FCN!=0 & more frags | | FCN!=0 & more frags
+======++ ~~~~~~~~~~~~~~~~~~~~~~ +======++ ~~~~~~~~~~~~~~~~~~~~~~
Frag RuleID trigger | +--+ Send cur_W + frag(FCN); Frag RuleID trigger | +--+ Send cur_W + frag(FCN);
~~~~~~~~~~~~~~~~~~~ | | | FCN--; ~~~~~~~~~~~~~~~~~~~ | | | FCN--;
skipping to change at page 75, line 36 skipping to change at page 78, line 36
* size of RCS and algorithm for its computation, for each Rule * size of RCS and algorithm for its computation, for each Rule
ID, if different from the default CRC32. Byte fill-up with ID, if different from the default CRC32. Byte fill-up with
zeroes or other mechanism, to be specified. zeroes or other mechanism, to be specified.
* Retransmission Timer duration for each Rule ID value, if * Retransmission Timer duration for each Rule ID value, if
applicable to the SCHC F/R mode applicable to the SCHC F/R mode
* Inactivity Timer duration for each Rule ID value, if applicable * Inactivity Timer duration for each Rule ID value, if applicable
to the SCHC F/R mode to the SCHC F/R mode
* MAX_ACK_REQUEST value for each Rule ID value, if applicable to * MAX_ACK_REQUESTS value for each Rule ID value, if applicable to
the SCHC F/R mode the SCHC F/R mode
o if L2 Word is wider than a bit and SCHC fragmentation is used, o if L2 Word is wider than a bit and SCHC fragmentation is used,
value of the padding bits (0 or 1). This is needed because the value of the padding bits (0 or 1). This is needed because the
padding bits of the last fragment are included in the RCS padding bits of the last fragment are included in the RCS
computation. computation.
A Profile may define a delay to be added after each SCHC message A Profile may define a delay to be added after each SCHC message
transmission for compliance with local regulations or other transmission for compliance with local regulations or other
constraints imposed by the applications. constraints imposed by the applications.
skipping to change at page 76, line 27 skipping to change at page 79, line 27
Appendix E. Supporting multiple window sizes for fragmentation Appendix E. Supporting multiple window sizes for fragmentation
For ACK-Always or ACK-on-Error, implementers may opt to support a For ACK-Always or ACK-on-Error, implementers may opt to support a
single window size or multiple window sizes. The latter, when single window size or multiple window sizes. The latter, when
feasible, may provide performance optimizations. For example, a feasible, may provide performance optimizations. For example, a
large window size should be used for packets that need to be split large window size should be used for packets that need to be split
into a large number of tiles. However, when the number of tiles into a large number of tiles. However, when the number of tiles
required to carry a packet is low, a smaller window size, and thus a required to carry a packet is low, a smaller window size, and thus a
shorter Bitmap, may be sufficient to provide reception status on all shorter Bitmap, may be sufficient to provide reception status on all
tiles. If multiple window sizes are supported, the Rule ID may tiles. If multiple window sizes are supported, the Rule ID signals
signal the window size in use for a specific packet transmission. the window size in use for a specific packet transmission.
The same window size MUST be used for the transmission of all tiles Appendix F. ACK-Always and ACK-on-Error on quasi-bidirectional links
that belong to the same SCHC Packet.
Appendix F. Downlink SCHC Fragment transmission The ACK-Always and ACK-on-Error modes of SCHC F/R are bidirectional
protocols: they require a feedback path from the reassembler to the
fragmenter.
Some LPWAN technologies provide quasi-bidirectional connectivity,
whereby a downlink transmission from the Network Infrastructure can
only take place right after an uplink transmission by the Dev.
When using SCHC F/R to send fragmented SCHC Packets downlink over
these quasi-bidirectional links, the following situation may arise:
if an uplink SCHC ACK is lost, the SCHC ACK REQ message by the sender
could be stuck indefinitely in the downlink queue at the Network
Infrastructure, waiting for a transmission opportunity.
There are many ways by which this deadlock can be avoided. The Dev
application might be sending recurring uplink messages such as keep-
alive, or the Dev application stack might be sending other recurring
uplink messages as part of its operation. However, these are out of
the control of this generic SCHC specification.
In order to cope with quasi-bidirectional links, a SCHC-over-foo
specification may want to amend the SCHC F/R specification to add a
timer-based retransmission of the SCHC ACK. Below is an example of
the suggested behavior for ACK-Always mode. Because it is an
example, [RFC2119] language is deliberately not used here.
For downlink transmission of a fragmented SCHC Packet in ACK-Always For downlink transmission of a fragmented SCHC Packet in ACK-Always
mode, the SCHC Fragment receiver may support timer-based SCHC ACK mode, the SCHC Fragment receiver may support timer-based SCHC ACK
retransmission. In this mechanism, the SCHC Fragment receiver retransmission. In this mechanism, the SCHC Fragment receiver
initializes and starts a timer (the Inactivity Timer is used) after initializes and starts a timer (the UplinkACK Timer) after the
the transmission of a SCHC ACK, except when the SCHC ACK is sent in transmission of a SCHC ACK, except when the SCHC ACK is sent in
response to the last SCHC Fragment of a packet (All-1 fragment). In response to the last SCHC Fragment of a packet (All-1 fragment). In
the latter case, the SCHC Fragment receiver does not start a timer the latter case, the SCHC Fragment receiver does not start a timer
after transmission of the SCHC ACK. after transmission of the SCHC ACK.
If, after transmission of a SCHC ACK that is not an All-1 fragment, If, after transmission of a SCHC ACK that is not an All-1 fragment,
and before expiration of the corresponding Inactivity timer, the SCHC and before expiration of the corresponding UplinkACK timer, the SCHC
Fragment receiver receives a SCHC Fragment that belongs to the Fragment receiver receives a SCHC Fragment that belongs to the
current window (e.g. a missing SCHC Fragment from the current window) current window (e.g. a missing SCHC Fragment from the current window)
or to the next window, the Inactivity timer for the SCHC ACK is or to the next window, the UplinkACK timer for the SCHC ACK is
stopped. However, if the Inactivity timer expires, the SCHC ACK is stopped. However, if the UplinkACK timer expires, the SCHC ACK is
resent and the Inactivity timer is reinitialized and restarted. resent and the UplinkACK timer is reinitialized and restarted.
The default initial value for the Inactivity Timer, as well as the The default initial value for the UplinkACK Timer, as well as the
maximum number of retries for a specific SCHC ACK, denoted maximum number of retries for a specific SCHC ACK, denoted
MAX_ACK_RETRIES, are not defined in this document, and need to be MAX_ACK_REQUESTS, is to be defined in a Profile. The initial value
defined in a Profile. The initial value of the Inactivity timer is of the UplinkACK timer is expected to be greater than that of the
expected to be greater than that of the Retransmission timer, in Retransmission timer, in order to make sure that a (buffered) SCHC
order to make sure that a (buffered) SCHC Fragment to be Fragment to be retransmitted finds an opportunity for that
retransmitted can find an opportunity for that transmission. One transmission. One exception to this recommendation is the special
exception to this recommendation is the special case of the All-1 case of the All-1 SCHC Fragment transmission.
SCHC Fragment transmission.
When the SCHC Fragment sender transmits the All-1 SCHC Fragment, it When the SCHC Fragment sender transmits the All-1 SCHC Fragment, it
starts its Retransmission Timer with a large timeout value (e.g. starts its Retransmission Timer with a large timeout value (e.g.
several times that of the initial Inactivity Timer). If a SCHC ACK several times that of the initial UplinkACK Timer). If a SCHC ACK is
is received before expiration of this timer, the SCHC Fragment sender received before expiration of this timer, the SCHC Fragment sender
retransmits any lost SCHC Fragments reported by the SCHC ACK, or if retransmits any lost SCHC Fragments as reported by the SCHC ACK, or
the SCHC ACK confirms successful reception of all SCHC Fragments of if the SCHC ACK confirms successful reception of all SCHC Fragments
the last window, the transmission of the fragmented SCHC Packet is of the last window, the transmission of the fragmented SCHC Packet is
considered complete. If the timer expires, and no SCHC ACK has been considered complete. If the timer expires, and no SCHC ACK has been
received since the start of the timer, the SCHC Fragment sender received since the start of the timer, the SCHC Fragment sender
assumes that the All-1 SCHC Fragment has been successfully received assumes that the All-1 SCHC Fragment has been successfully received
(and possibly, the last SCHC ACK has been lost: this mechanism (and possibly, the last SCHC ACK has been lost: this mechanism
assumes that the Retransmission Timer for the All-1 SCHC Fragment is assumes that the Retransmission Timer for the All-1 SCHC Fragment is
long enough to allow several SCHC ACK retries if the All-1 SCHC long enough to allow several SCHC ACK retries if the All-1 SCHC
Fragment has not been received by the SCHC Fragment receiver, and it Fragment has not been received by the SCHC Fragment receiver, and it
also assumes that it is unlikely that several ACKs become all lost). also assumes that it is unlikely that several ACKs become all lost).
Authors' Addresses Authors' Addresses
 End of changes. 149 change blocks. 
436 lines changed or deleted 672 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/