< draft-ietf-lpwan-ipv6-static-context-hc-07.txt   draft-ietf-lpwan-ipv6-static-context-hc-08.txt >
lpwan Working Group A. Minaburo lpwan Working Group A. Minaburo
Internet-Draft Acklio Internet-Draft Acklio
Intended status: Informational L. Toutain Intended status: Informational L. Toutain
Expires: April 23, 2018 IMT-Atlantique Expires: June 20, 2018 IMT-Atlantique
C. Gomez C. Gomez
Universitat Politecnica de Catalunya Universitat Politecnica de Catalunya
October 20, 2017 December 17, 2017
LPWAN Static Context Header Compression (SCHC) and fragmentation for LPWAN Static Context Header Compression (SCHC) and fragmentation for
IPv6 and UDP IPv6 and UDP
draft-ietf-lpwan-ipv6-static-context-hc-07 draft-ietf-lpwan-ipv6-static-context-hc-08
Abstract Abstract
This document describes a header compression scheme and fragmentation This document describes a header compression scheme and fragmentation
functionality for very low bandwidth networks. These techniques are functionality for very low bandwidth networks. These techniques are
specially tailored for LPWAN (Low Power Wide Area Network) networks. specially tailored for Low Power Wide Area Network (LPWAN).
The Static Context Header Compression (SCHC) offers a great level of The Static Context Header Compression (SCHC) offers a great level of
flexibility when processing the header fields. SCHC compression is flexibility when processing the header fields. SCHC compression is
based on a common static context stored in a LPWAN device and in the based on a common static context stored in a LPWAN device and in the
network. Static context means that the stored information does not network. Static context means that the stored information does not
change during the packet transmission. The context describes the change during packet transmission. The context describes the field
field values and keeps information that will not be transmitted values and keeps information that will not be transmitted through the
through the constrained network. constrained network.
SCHC must be used for LPWAN networks because it avoids complex SCHC must be used for LPWAN networks because it avoids complex
resynchronization mechanisms, which are incompatible with LPWAN resynchronization mechanisms, which are incompatible with LPWAN
characteristics. And also because in most cases, IPv6/UDP headers characteristics. And also, because with SCHC, in most cases IPv6/UDP
are reduced to a small identifier called Rule ID. Eventhough headers can be reduced to a small identifier called Rule ID. Even
sometimes, a SCHC compressed packet will not fit in one L2 PDU, and though, sometimes, a SCHC compressed packet will not fit in one L2
the SCHC fragmentation protocol will be used. The SCHC fragmentation PDU, and the SCHC fragmentation protocol defined in this document may
and reassembly mechanism is used in two situations: for SCHC- be used.
compressed packets that still exceed the L2 PDU size; and for the
case where the SCHC compression cannot be performed.
This document describes the SCHC compression/decompression framework This document describes the SCHC compression/decompression framework
and applies it to IPv6/UDP headers. This document also specifies a and applies it to IPv6/UDP headers. This document also specifies a
fragmentation and reassembly mechanism that is used to support the fragmentation and reassembly mechanism that is used to support the
IPv6 MTU requirement over LPWAN technologies. Fragmentation is IPv6 MTU requirement over LPWAN technologies. Fragmentation is
mandatory for IPv6 datagrams that, after SCHC compression or when it mandatory for IPv6 datagrams that, after SCHC compression or when it
has not been possible to apply such compression, still exceed the L2 has not been possible to apply such compression, still exceed the L2
maximum payload size. Similar solutions for other protocols such as maximum payload size. Similar solutions for other protocols such as
CoAP will be described in separate documents. CoAP will be described in separate documents.
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 April 23, 2018. This Internet-Draft will expire on June 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 46 skipping to change at page 2, line 46
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 4 2. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Static Context Header Compression . . . . . . . . . . . . . . 7 4. Static Context Header Compression . . . . . . . . . . . . . . 7
4.1. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Packet processing . . . . . . . . . . . . . . . . . . . . 10 4.3. Packet processing . . . . . . . . . . . . . . . . . . . . 10
4.4. Matching operators . . . . . . . . . . . . . . . . . . . 11 4.4. Matching operators . . . . . . . . . . . . . . . . . . . 12
4.5. Compression Decompression Actions (CDA) . . . . . . . . . 12 4.5. Compression Decompression Actions (CDA) . . . . . . . . . 12
4.5.1. not-sent CDA . . . . . . . . . . . . . . . . . . . . 13 4.5.1. not-sent CDA . . . . . . . . . . . . . . . . . . . . 13
4.5.2. value-sent CDA . . . . . . . . . . . . . . . . . . . 13 4.5.2. value-sent CDA . . . . . . . . . . . . . . . . . . . 13
4.5.3. mapping-sent . . . . . . . . . . . . . . . . . . . . 13 4.5.3. mapping-sent . . . . . . . . . . . . . . . . . . . . 14
4.5.4. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 13 4.5.4. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.5. DEViid, APPiid CDA . . . . . . . . . . . . . . . . . 14 4.5.5. DEViid, APPiid CDA . . . . . . . . . . . . . . . . . 14
4.5.6. Compute-* . . . . . . . . . . . . . . . . . . . . . . 14 4.5.6. Compute-* . . . . . . . . . . . . . . . . . . . . . . 14
5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Reliability options . . . . . . . . . . . . . . . . . . . 15 5.2. Functionalities . . . . . . . . . . . . . . . . . . . . . 15
5.3. Functionalities . . . . . . . . . . . . . . . . . . . . . 16 5.3. Delivery Reliability options . . . . . . . . . . . . . . 18
5.4. Formats . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.4. Fragmentation Frames Formats . . . . . . . . . . . . . . 19
5.4.1. Fragment format . . . . . . . . . . . . . . . . . . . 18 5.4.1. Fragment format . . . . . . . . . . . . . . . . . . . 19
5.4.2. Fragmentation header formats . . . . . . . . . . . . 18 5.4.2. Fragmentation formats . . . . . . . . . . . . . . . . 20
5.4.3. ACK format . . . . . . . . . . . . . . . . . . . . . 19 5.4.3. ACK format . . . . . . . . . . . . . . . . . . . . . 20
5.4.4. All-1 and All-0 formats . . . . . . . . . . . . . . . 20 5.4.4. All-1 and All-0 formats . . . . . . . . . . . . . . . 21
5.5. Baseline mechanism . . . . . . . . . . . . . . . . . . . 21 5.4.5. Abort formats . . . . . . . . . . . . . . . . . . . . 23
5.6. Supporting multiple window sizes . . . . . . . . . . . . 22 5.5. Baseline mechanism . . . . . . . . . . . . . . . . . . . 23
5.7. Aborting fragmented datagram transmissions . . . . . . . 23 5.5.1. No ACK . . . . . . . . . . . . . . . . . . . . . . . 24
5.8. Downlink fragment transmission . . . . . . . . . . . . . 23 5.5.2. The Window modes . . . . . . . . . . . . . . . . . . 25
5.9. Fragmentation Mode of Operation Description . . . . . . . 23 5.5.3. Bitmap Optimization . . . . . . . . . . . . . . . . . 28
5.9.1. No ACK Mode . . . . . . . . . . . . . . . . . . . . . 23 5.6. Supporting multiple window sizes . . . . . . . . . . . . 30
5.9.2. The Window modes . . . . . . . . . . . . . . . . . . 25 5.7. Downlink fragment transmission . . . . . . . . . . . . . 31
5.9.3. ACK Always . . . . . . . . . . . . . . . . . . . . . 25 6. Padding management . . . . . . . . . . . . . . . . . . . . . 32
5.9.4. ACK on error . . . . . . . . . . . . . . . . . . . . 30 7. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 32
6. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 35 7.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 32
6.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 35 7.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 32
6.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 35 7.3. Flow label field . . . . . . . . . . . . . . . . . . . . 33
6.3. Flow label field . . . . . . . . . . . . . . . . . . . . 35 7.4. Payload Length field . . . . . . . . . . . . . . . . . . 33
6.4. Payload Length field . . . . . . . . . . . . . . . . . . 36 7.5. Next Header field . . . . . . . . . . . . . . . . . . . . 33
6.5. Next Header field . . . . . . . . . . . . . . . . . . . . 36 7.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . . 34
6.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . . 36 7.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . . 34
6.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . . 37 7.7.1. IPv6 source and destination prefixes . . . . . . . . 34
6.7.1. IPv6 source and destination prefixes . . . . . . . . 37 7.7.2. IPv6 source and destination IID . . . . . . . . . . . 35
6.7.2. IPv6 source and destination IID . . . . . . . . . . . 37 7.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . . 35
6.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . . 38 7.9. UDP source and destination port . . . . . . . . . . . . . 35
6.9. UDP source and destination port . . . . . . . . . . . . . 38 7.10. UDP length field . . . . . . . . . . . . . . . . . . . . 36
6.10. UDP length field . . . . . . . . . . . . . . . . . . . . 38 7.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 36
6.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 39 8. Security considerations . . . . . . . . . . . . . . . . . . . 36
7. Security considerations . . . . . . . . . . . . . . . . . . . 39 8.1. Security considerations for header compression . . . . . 36
7.1. Security considerations for header compression . . . . . 39 8.2. Security considerations for fragmentation . . . . . . . . 36
7.2. Security considerations for fragmentation . . . . . . . . 39 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 10.1. Normative References . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . 40 10.2. Informative References . . . . . . . . . . . . . . . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . 41 Appendix A. SCHC Compression Examples . . . . . . . . . . . . . 38
Appendix A. SCHC Compression Examples . . . . . . . . . . . . . 41 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 41
Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 44 Appendix C. Fragmentation State Machines . . . . . . . . . . . . 47
Appendix C. Allocation of Rule IDs for fragmentation . . . . . . 50 Appendix D. Allocation of Rule IDs for fragmentation . . . . . . 54
Appendix D. Note . . . . . . . . . . . . . . . . . . . . . . . . 51 Appendix E. Note . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
Header compression is mandatory to efficiently bring Internet Header compression is mandatory to efficiently bring Internet
connectivity to the node within a LPWAN network. Some LPWAN networks connectivity to the node within a LPWAN network. Some LPWAN networks
properties can be exploited to get an efficient header compression: properties can be exploited to get an efficient header compression:
o Topology is star-oriented, therefore all the packets follow the o Topology is star-oriented; therefore, all the packets follow the
same path. For the needs of this draft, the architecture can be same path. For the needs of this draft, the architecture can be
summarized to Devices (Dev) exchanging information with LPWAN summarized to Devices (Dev) exchanging information with LPWAN
Application Server (App) through a Network Gateway (NGW). Application Server (App) through a Network Gateway (NGW).
o Traffic flows are mostly known in advance since devices embed o Traffic flows are mostly known in advance since devices embed
built-in applications. Contrary to computers or smartphones, new built-in applications. Contrary to computers or smartphones, new
applications cannot be easily installed. applications cannot be easily installed.
The Static Context Header Compression (SCHC) is defined for this The Static Context Header Compression (SCHC) is defined for this
environment. SCHC uses a context where header information is kept in environment. SCHC uses a context where header information is kept in
skipping to change at page 5, line 5 skipping to change at page 5, line 5
2. LPWAN Architecture 2. LPWAN Architecture
LPWAN technologies have similar architectures but different LPWAN technologies have similar architectures but different
terminology. We can identify different types of entities in a terminology. We can identify different types of entities in a
typical LPWAN network, see Figure 1: 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 high density of devices per radio actuators, etc.). There can be a high density of devices per radio
gateway. gateway.
o The Radio Gateway (RG), which is the end point of the constrained o The Radio Gateway (RGW), which 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 LPWAN-AAA Server, which controls the user authentication and the o LPWAN-AAA Server, which controls the user authentication and the
applications. We use the term LPWAN-AAA server because we are not applications.
assuming that this entity speaks RADIUS or Diameter as many/most AAA
servers do, but equally we don't want to rule that out, as the
functionality will be similar.
o Application Server (App) o Application Server (App)
+------+ +------+
() () () | |LPWAN-| () () () | |LPWAN-|
() () () () / \ +---------+ | AAA | () () () () / \ +---------+ | AAA |
() () () () () () / \=====| ^ |===|Server| +-----------+ () () () () () () / \=====| ^ |===|Server| +-----------+
() () () | | <--|--> | +------+ |APPLICATION| () () () | | <--|--> | +------+ |APPLICATION|
() () () () / \==========| v |=============| (App) | () () () () / \==========| v |=============| (App) |
() () () / \ +---------+ +-----------+ () () () / \ +---------+ +-----------+
Dev Radio Gateways NGW Dev Radio Gateways NGW
Figure 1: LPWAN Architecture Figure 1: LPWAN Architecture
3. Terminology 3. Terminology
This section defines the terminology and acronyms used in this This section defines the terminology and acronyms used in this
document. document.
o All-0. Fragmentation Packet format to send the last frame of a
window.
o All-1. Fragmentation Packet format to send the last frame of a
packet.
o All-0 empty. Fragmentation Packet format without payload to
request the bitmap when the Retransmission Timer expires in a
window.
o All-1 empty. Fragmentation Packet format without payload to
request the bitmap when the Retransmission Timer expires in the
last window.
o App: LPWAN Application. An application sending/receiving IPv6 o App: LPWAN Application. An application sending/receiving IPv6
packets to/from the Device. packets to/from the Device.
o APP-IID: Application Interface Identifier. Second part of the o APP-IID: Application Interface Identifier. Second part of the
IPv6 address to identify the application interface IPv6 address to identify the application interface
o Bi: Bidirectional, it can be used in both senses o Bi: Bidirectional, a rule entry that applies in both directions.
o C: Checked bit. Used in fragmentation header to determine when
the MIC is correct (1) or not (0).
o CDA: Compression/Decompression Action. An action that is o CDA: Compression/Decompression Action. An action that is
performed for both functionalities to compress a header field or performed for both functionalities to compress a header field or
to recover its original value in the decompression phase. to recover its original value in the decompression phase.
o Context: A set of rules used to compress/decompress headers o Context: A set of rules used to compress/decompress headers
o Dev: Device. A Node connected to the LPWAN. A Dev may implement o Dev: Device. A Node connected to the LPWAN. A Dev may implement
SCHC. SCHC.
skipping to change at page 6, line 27 skipping to change at page 6, line 41
that carries an efficient representation of a larger-sized that carries an efficient representation of a larger-sized
fragment number. fragment number.
o FID: Field Identifier is an index to describe the header fields in o FID: Field Identifier is an index to describe the header fields in
the Rule the Rule
o FL: Field Length is a value to identify if the field is fixed or o FL: Field Length is a value to identify if the field is fixed or
variable length. variable length.
o FP: Field Position is a value that is used to identify each o FP: Field Position is a value that is used to identify each
instance a field apears in the header. instance a field appears in the header.
o IID: Interface Identifier. See the IPv6 addressing architecture o IID: Interface Identifier. See the IPv6 addressing architecture
[RFC7136] [RFC7136]
o Inactivity Timer. Timer to End the state machine when there is an
error and there is no possibility to continue the transmission.
o MIC: Message Integrity Check. A fragmentation header field o MIC: Message Integrity Check. A fragmentation header field
computed over an IPv6 packet before fragmentation, used for error computed over an IPv6 packet before fragmentation, used for error
detection after IPv6 packet reassembly. detection after IPv6 packet reassembly.
o MO: Matching Operator. An operator used to match a value o MO: Matching Operator. An operator used to match a value
contained in a header field with a value contained in a Rule. contained in a header field with a value contained in a Rule.
o Retransmission Timer. Timer used in the sender transmission to
detect error in the link when waiting for an ACK.
o Rule: A set of header field values. o Rule: A set of header field values.
o Rule entry: A row in the rule that describes a header field.
o Rule ID: An identifier for a rule, SCHC C/D, and Dev share the o Rule ID: An identifier for a rule, SCHC C/D, and Dev share the
same Rule ID for a specific flow. A set of Rule IDs are used to same Rule ID for a specific flow. A set of Rule IDs are used to
support fragmentation functionality. support fragmentation functionality.
o SCHC C/D: Static Context Header Compression Compressor/ o SCHC C/D: Static Context Header Compression Compressor/
Decompressor. A process in the network to achieve compression/ Decompressor. A process in the network to achieve compression/
decompressing headers. SCHC C/D uses SCHC rules to perform decompressing headers. SCHC C/D uses SCHC rules to perform
compression and decompression. compression and decompression.
o TV: Target value. A value contained in the Rule that will be o TV: Target value. A value contained in the Rule that will be
skipping to change at page 7, line 21 skipping to change at page 7, line 43
4. Static Context Header Compression 4. Static Context Header Compression
Static Context Header Compression (SCHC) avoids context Static Context Header Compression (SCHC) avoids context
synchronization, which is the most bandwidth-consuming operation in synchronization, which is the most bandwidth-consuming operation in
other header compression mechanisms such as RoHC [RFC5795]. Based on other header compression mechanisms such as RoHC [RFC5795]. Based on
the fact that the nature of data flows is highly predictable in LPWAN the fact that the nature of data flows is highly predictable in LPWAN
networks, some static contexts may be stored on the Device (Dev). networks, some static contexts may be stored on the Device (Dev).
The contexts must be stored in both ends, and it can either be The contexts must be stored in both ends, and it can either be
learned by a provisioning protocol or by out of band means or it can learned by a provisioning protocol or by out of band means or it can
be pre-provisioned, etc. The way the context is learned on both be pre-provisioned, etc. The way the context is learned on both
sides is out of the scope of this document. sides are out of the scope of this document.
Dev App Dev App
+--------------+ +--------------+ +--------------+ +--------------+
|APP1 APP2 APP3| |APP1 APP2 APP3| |APP1 APP2 APP3| |APP1 APP2 APP3|
| | | | | | | |
| UDP | | UDP | | UDP | | UDP |
| IPv6 | | IPv6 | | IPv6 | | IPv6 |
| | | | | | | |
| SCHC C/D | | | | SCHC C/D | | |
| (context) | | | | (context) | | |
skipping to change at page 7, line 43 skipping to change at page 8, line 25
| +--+ +----+ +---------+ . | +--+ +----+ +---------+ .
+~~ |RG| === |NGW | === |SCHC C/D |... Internet .. +~~ |RG| === |NGW | === |SCHC C/D |... Internet ..
+--+ +----+ |(context)| +--+ +----+ |(context)|
+---------+ +---------+
Figure 2: Architecture Figure 2: Architecture
Figure 2 represents the architecture for compression/decompression, Figure 2 represents the architecture for compression/decompression,
it is based on [I-D.ietf-lpwan-overview] terminology. The Device is it is based on [I-D.ietf-lpwan-overview] terminology. The Device is
sending applications flows using IPv6 or IPv6/UDP protocols. These sending applications flows using IPv6 or IPv6/UDP protocols. These
flows are compressed by an Static Context Header Compression flows are compressed by a Static Context Header Compression
Compressor/Decompressor (SCHC C/D) to reduce headers size. The Compressor/Decompressor (SCHC C/D) to reduce headers size. The
resulting information is sent to a layer two (L2) frame to a LPWAN resulting information is sent to a layer two (L2) frame to a LPWAN
Radio Network (RG) which forwards the frame to a Network Gateway Radio Network (RG) which forwards the frame to a Network Gateway
(NGW). The NGW sends the data to an SCHC C/D for decompression which (NGW). The NGW sends the data to an SCHC C/D for decompression which
shares the same rules with the Dev. The SCHC C/D can be located on shares the same rules with the Dev. The SCHC C/D can be located on
the Network Gateway (NGW) or in another place as long as a tunnel is the Network Gateway (NGW) or in another place as long as a tunnel is
established between the NGW and the SCHC C/D. The SCHC C/D in both established between the NGW and the SCHC C/D. The SCHC C/D in both
sides must share the same set of Rules. After decompression, the sides must share the same set of Rules. After decompression, the
packet can be sent on the Internet to one or several LPWAN packet can be sent on the Internet to one or several LPWAN
Application Servers (App). Application Servers (App).
skipping to change at page 8, line 47 skipping to change at page 9, line 28
||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||
|+-------+--+--+--+------------+-----------------+---------------+|/ |+-------+--+--+--+------------+-----------------+---------------+|/
| | | |
\-----------------------------------------------------------------/ \-----------------------------------------------------------------/
Figure 3: Compression/Decompression Context Figure 3: Compression/Decompression Context
The Rule does not describe the original packet format which must be The Rule does not describe the original packet format which must be
known from the compressor/decompressor. The rule just describes the known from the compressor/decompressor. The rule just describes the
compression/decompression behavior for the header fields. In the compression/decompression behavior for the header fields. In the
rule, the description of the header field must be performed in the rule, the description of the header field should be performed in the
format packet order. format packet order.
The Rule also describes the compressed header fields which are The Rule also describes the compressed header fields which are
transmitted regarding their position in the rule which is used for transmitted regarding their position in the rule which is used for
data serialization on the compressor side and data deserialization on data serialization on the compressor side and data deserialization on
the decompressor side. the decompressor side.
The Context describes the header fields and its values with the The Context describes the header fields and its values with the
following entries: following entries:
skipping to change at page 9, line 36 skipping to change at page 10, line 16
packets sent by the Dev to the App, packets sent by the Dev to the App,
* DOWNLINK (Dw) when the field or the value is only present in * DOWNLINK (Dw) when the field or the value is only present in
packet sent from the App to the Dev and packet sent from the App to the Dev and
* BIDIRECTIONAL (Bi) when the field or the value is present * BIDIRECTIONAL (Bi) when the field or the value is present
either upstream or downstream. either upstream or downstream.
o A Target Value (TV) is the value used to make the comparison with o A Target Value (TV) is the value used to make the comparison with
the packet header field. The Target Value can be of any type the packet header field. The Target Value can be of any type
(integer, strings,...). For instance, it can be a single value or (integer, strings, etc.). For instance, it can be a single value
a more complex structure (array, list,...), such as a JSON or a or a more complex structure (array, list, etc.), such as a JSON or
CBOR structure. a CBOR structure.
o A Matching Operator (MO) is the operator used to make the o A Matching Operator (MO) is the operator used to make the
comparison between the Field Value and the Target Value. The comparison between the Field Value and the Target Value. The
Matching Operator may require some parameters. MO is only used Matching Operator may require some parameters. MO is only used
during the compression phase. during the compression phase.
o A Compression Decompression Action (CDA) is used to describe the o A Compression Decompression Action (CDA) is used to describe the
compression and the decompression process. The CDA may require compression and the decompression process. The CDA may require
some parameters, CDA are used in both compression and some parameters, CDA are used in both compression and
decompression phases. decompression phases.
skipping to change at page 10, line 27 skipping to change at page 10, line 52
different header compression. To identify the correct Rule ID, the different header compression. To identify the correct Rule ID, the
SCHC C/D needs to combine the Rule ID with the Dev L2 identifier to SCHC C/D needs to combine the Rule ID with the Dev L2 identifier to
find the appropriate Rule. find the appropriate Rule.
4.3. Packet processing 4.3. Packet processing
The compression/decompression process follows several steps: The compression/decompression process follows several steps:
o compression Rule selection: The goal is to identify which Rule(s) o compression Rule selection: The goal is to identify which Rule(s)
will be used to compress the packet's headers. When doing will be used to compress the packet's headers. When doing
compression from Dw to Up the SCHC C/D needs to find the correct compression in the NGW side the SCHC C/D needs to find the correct
Rule to be used by identifying its Dev-ID and the Rule-ID. In the Rule to be used by identifying its Dev-ID and the Rule-ID. In the
Up situation, only the Rule-ID is used. The next step is to Dev, only the Rule-ID may be used. The next step is to choose the
choose the fields by their direction, using the direction fields by their direction, using the direction indicator (DI), so
indicator (DI), so the fields that do not correspond to the the fields that do not correspond to the appropriated DI will be
appropriated DI will be excluded. Next, then the fields are excluded. Next, then the fields are identified according to their
identified according to their field identifier (FID) and field field identifier (FID) and field position (FP). If the field
position (FP). If the field position does not correspond, then position does not correspond, then the Rule is not used and the
the Rule is not used and the SCHC take next Rule. Once the DI and SCHC take next Rule. Once the DI and the FP correspond to the
the FP correspond to the header information, each field's value is header information, each field's value is then compared to the
then compared to the corresponding target value (TV) stored in the corresponding target value (TV) stored in the Rule for that
Rule for that specific field using the matching operator (MO). If specific field using the matching operator (MO). If all the
all the fields in the packet's header satisfy all the matching fields in the packet's header satisfy all the matching operators
operators (MOs) of a Rule (i.e. all results are True), the fields (MOs) of a Rule (i.e. all results are True), the fields of the
of the header are then processed according to the Compression/ header are then processed according to the Compression/
Decompression Actions (CDAs) and a compressed header is obtained. Decompression Actions (CDAs) and a compressed header is obtained.
Otherwise, the next rule is tested. If no eligible rule is found, Otherwise, the next rule is tested. If no eligible rule is found,
then the header must be sent without compression, in which case then the header must be sent without compression, in which case
the fragmentation process must be required. the fragmentation process must be required.
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
information resulting from the compression of header fields, information resulting from the compression of header fields,
directly followed by the payload. The product of field directly followed by the payload. The product of field
compression is sent in the order expressed in the Rule for the compression is sent in the order expressed in the Rule for the
matching fields. The way the Rule ID is sent depends on the matching fields. The way the Rule ID is sent depends on the
specific LPWAN layer two technology and will be specified in a specific LPWAN layer two technology and will be specified in a
specific document and is out of the scope of this document. For specific document and is out of the scope of this document. For
example, it can be either included in a Layer 2 header or sent in example, it can be either included in a Layer 2 header or sent in
the first byte of the L2 payload. (Cf. Figure 4). the first byte of the L2 payload. (Cf. Figure 4).
o decompression: In both directions, The receiver identifies the o decompression: In both directions, the receiver identifies the
sender through its device-id (e.g. MAC address) and selects the sender through its device-id (e.g. MAC address) and selects the
appropriate Rule through the Rule ID. This Rule gives the appropriate Rule through the Rule ID. This Rule gives the
compressed header format and associates these values to the header compressed header format and associates these values to the header
fields. It applies the CDA action to reconstruct the original fields. It applies the CDA action to reconstruct the original
header fields. The CDA application order can be different from header fields. The CDA application order can be different from
the order given by the Rule. For instance Compute-* may be the order given by the Rule. For instance, Compute-* may be
applied at the end, after all the other CDAs. applied at the end, after all the other CDAs.
If after using SCHC compression and adding the payload to the L2 If after using SCHC compression and adding the payload to the L2
frame the datagram is not multiple of 8 bits, padding may be used. frame the datagram is not multiple of 8 bits, padding may be used.
+--- ... --+-------------- ... --------------+-----------+--...--+ +--- ... --+-------------- ... --------------+-----------+--...--+
| Rule ID |Compressed Hdr Fields information| payload |padding| | Rule ID |Compressed Hdr Fields information| payload |padding|
+--- ... --+-------------- ... --------------+-----------+--...--+ +--- ... --+-------------- ... --------------+-----------+--...--+
Figure 4: LPWAN Compressed Format Packet Figure 4: LPWAN Compressed Format Packet
skipping to change at page 13, line 31 skipping to change at page 14, line 7
The value-sent action is generally used when the field value is not The value-sent action is generally used when the field value is not
known by both Compressor and Decompressor. The value is sent in the known by both Compressor and Decompressor. The value is sent in the
compressed message header. Both Compressor and Decompressor must compressed message header. Both Compressor and Decompressor must
know the size of the field, either implicitly (the size is known by know the size of the field, either implicitly (the size is known by
both sides) or explicitly in the compressed header field by both sides) or explicitly in the compressed header field by
indicating the length. This function is generally used with the indicating the length. This function is generally used with the
"ignore" MO. "ignore" MO.
4.5.3. mapping-sent 4.5.3. mapping-sent
mapping-sent is used to send a smaller index associated with the list The mapping-sent is used to send a smaller index associated with the
of values in the Target Value. This function is used together with list of values in the Target Value. This function is used together
the "match-mapping" MO. with the "match-mapping" MO.
The compressor looks on the TV to find the field value and send the The compressor looks on the TV to find the field value and send the
corresponding index. The decompressor uses this index to restore the corresponding index. The decompressor uses this index to restore the
field value. field value.
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 indexes. possible indexes.
4.5.4. LSB CDA 4.5.4. LSB CDA
LSB action is used to avoid sending the known part of the packet LSB action is used to avoid sending the known part of the packet
field header to the other end. This action is used together with the field header to the other end. This action is used together with the
"MSB" MO. A length can be specified in the rule to indicate how many "MSB" MO. A length can be specified in the rule to indicate how many
bits have to be sent. If the length is not specified, the number of bits have to be sent. If the length is not specified, the number of
bits sent is the field length minus the bits length specified in the bits sent is the field length minus the bits' length specified in the
MSB MO. MSB MO.
The compressor sends the "length" Least Significant Bits. The The compressor sends the "length" Least Significant Bits. The
decompressor combines the value received with the Target Value. decompressor combines the value received with the Target Value.
If this action is made on a variable length field, the remaining size If this action is made on a variable length field, the remaining size
in byte has to be sent before. in byte has to be sent before.
4.5.5. DEViid, APPiid CDA 4.5.5. DEViid, APPiid CDA
skipping to change at page 14, line 43 skipping to change at page 15, line 19
o compute-checksum: compute a checksum from the information already o compute-checksum: compute a checksum from the information already
received by the SCHC C/D. This field may be used to compute UDP received by the SCHC C/D. This field may be used to compute UDP
checksum. checksum.
5. Fragmentation 5. Fragmentation
5.1. Overview 5.1. Overview
In LPWAN technologies, the L2 data unit size typically varies from In LPWAN technologies, the L2 data unit size typically varies from
tens to hundreds of bytes. If the entire IPv6 datagram after tens to hundreds of bytes. If the entire IPv6 datagram after
applying SCHC header compression or when SCHC is not possible, fits applying SCHC header compression or when SCHC header compression is
within a single L2 data unit, the fragmentation mechanism is not used not possible, fits within a single L2 data unit, the fragmentation
and the packet is sent. Otherwise, the datagram SHALL be broken into mechanism is not used and the packet is sent. Otherwise, the
fragments. datagram SHALL be broken into fragments.
LPWAN technologies impose some strict limitations on traffic, devices LPWAN technologies impose some strict limitations on traffic, devices
are sleeping most of the time and may receive data during a short are sleeping most of the time and may receive data during a short
period of time after transmission to preserve battery. To adapt the period of time after transmission to preserve battery. To adapt the
SCHC fragmentation to the capabilities of LPWAN technologies, it is SCHC fragmentation to the capabilities of LPWAN technologies, it is
desirable to enable optional fragment retransmission and to allow a desirable to enable optional fragment retransmission and to allow a
gradation of fragment delivery reliability. This document does not gradation of fragment delivery reliability. This document does not
make any decision with regard to which fragment delivery reliability make any decision with regard to which fragment delivery reliability
option may be used over a specific LPWAN technology. option(s) will be used over a specific LPWAN technology.
An important consideration is that LPWAN networks typically follow An important consideration is that LPWAN networks typically follow
the star topology, and therefore data unit reordering is not expected the star topology, and therefore data unit reordering is not expected
in such networks. This specification assumes that reordering will in such networks. This specification assumes that reordering will
not happen between the entity performing fragmentation and the entity not happen between the entity performing fragmentation and the entity
performing reassembly. This assumption allows to reduce complexity performing reassembly. This assumption allows to reduce complexity
and overhead of the fragmentation mechanism. and overhead of the fragmentation mechanism.
5.2. Reliability options 5.2. Functionalities
This subsection describes the different fields in the fragmentation
header frames (see the fragmentation frames format in Section 5.4)
that are used to enable the fragmentation functionalities defined in
this document, and the different reliability options supported.
o Rule ID. The Rule ID is present in the fragmentation header and
in the ACK header format. The Rule ID is a fragmentation header
is used to identify that a fragment is being carried, the
fragmentation delivery reliability option used and it may indicate
the window size in use (if any). The Rule ID in the fragmentation
header also allows to interleave non-fragmented IPv6 datagrams
with fragments that carry a larger IPv6 datagram. The Rule ID in
an ACK allows to identify that the message is an ACK.
o Fragment Compressed Number (FCN). The FCN is included in all
fragments. This field can be understood as a truncated, efficient
representation of a larger-sized fragment number, and does not
carry an absolute fragment number. There are two FCN reserved
values that are used for controlling the fragmentation process, as
described next. The FCN value with all the bits equal to 1 (All-
1) denotes the last fragment of a packet. And the FCN value with
all the bits equal to 0 (All-0) denotes the last fragment of a
window (when such window is not the last one of the packet) in any
window mode or the fragments in No ACK mode. The rest of the FCN
values are assigned in a sequential and decreasing order, which
has the purpose to avoid possible ambiguity for the receiver that
might arise under certain conditions. In the fragments, this
field is an unsigned integer, with a size of N bits. In the No
ACK mode it is set to 1 bit (N=1). For the other reliability
options, it is recommended to use a number of bits (N) equal to or
greater than 3. Nevertheless, the apropriate value will be
defined in the corresponding technology documents. The FCN MUST
be set sequentially decreasing from the highest FCN in the window
(which will be used for the first fragment), and MUST wrap from 0
back to the highest FCN in the window.
For windows that are not the last one from a fragmented packet,
the FCN for the last fragment in such windows is an All-0. This
indicates that the window is finished and communication proceeds
according to the reliability option in use. The FCN for the last
fragment in the last window is an All-1. It is also important to
note that, for No ACK mode or N=1, the last fragment of the packet
will carry a FCN equal to 1, while all previous fragments will
carry a FCN of 0.
o Datagram Tag (DTag). The DTag field, if present, is set to the
same value for all fragments carrying the same IPv6 datagram.
This field allows to interleave fragments that correspond to
different IPv6 datagrams. In the fragment formats the size of the
DTag field is T bits, which may be set to a value greater than or
equal to 0 bits. DTag MUST be set sequentially increasing from 0
to 2^T - 1, and MUST wrap back from 2^T - 1 to 0. In the ACK
format, DTag carries the same value as the DTag field in the
fragments for which this ACK is intended.
o W (window): W is a 1-bit field. This field carries the same value
for all fragments of a window, and it is complemented for the next
window. The initial value for this field is 0. In the ACK
format, this field also has a size of 1 bit. In all ACKs, the W
bit carries the same value as the W bit carried by the fragments
whose reception is being positively or negatively acknowledged by
the ACK.
o Message Integrity Check (MIC). This field, which has a size of M
bits, is computed by the sender over the complete packet (i.e. a
SCHC compressed or an uncompressed IPv6 packet) before
fragmentation. The MIC allows the receiver to check errors in the
reassembled packet, while it also enables compressing the UDP
checksum by use of SCHC compression. The CRC32 as 0xEDB88320 is
recommended as the default algorithm for computing the MIC.
Nevertheless, other algorithm MAY be mandated in the corresponding
technology documents (e.g. technology-specific profiles).
o C (MIC checked): C is a 1-bit field. This field is used in the
ACK format packets to report the outcome of the MIC check, i.e.
whether the reassembled packet was correctly received or not.
o Retransmission Timer. It is used by a fragment sender after the
transmission of a window to detect a transmission error of the ACK
corresponding to this window. Depending on the reliability
option, it will lead to a request for an ACK retransmission on
ACK-Always or it will trigger the next window on ACK-on-error.
The dureation of this timer is not defined in this document and
must be defined in the corresponding technology documents (e.g.
technology-specific profiles).
o Inactivity Timer. This timer is used by a fragment receiver to
detect when there is a problem in the transmission of fragments
and the receiver does not get any fragment during a period of time
or a number of packets in a period of time. When this happens, an
Abort message needs to be sent. Initially, and each time a
fragment is received the timer is reinitialized. The duration of
this timer timer is not defined in this document and must be
defined in the specific technology document (e.g. technology-
specific profiles).
o Attempts. It is a counter used to request a missing ACK, and in
consequence to determine when an Abort is needed, because there
are recurrent fragment transmission errors, whose maximum value is
MAX_ACK_REQUESTS. The default value of MAX_ACK_REQUESTS is not
stated in this document, and it is expected to be defined in other
documents (e.g. technology-specific profiles).
o Bitmap. The Bitmap is a sequence of bits carried in an ACK for a
given window. Each bit in the Bitmap corresponds to a fragment of
the current window, and provides feedback on whether the fragment
has been received or not. The right-most position on the Bitmap
is used to report whether the All-0 or All-1 fragments have been
received or not. Feedback for a fragment with the highest FCN
value is provided by the left-most position in the Bitmap. In the
Bitmap, a bit set to 1 indicates that the corresponding FCN
fragment has been correctly sent and received. However, the
sending format of the bitmap will be truncated until a byte
boundary where the last error is given. However, when all the
Bitmap is transmitted, it may be truncated, see more details in
Section 5.5.3
o Abort. In case of error or when the Inactivity timer expires or
the MAX_ACK_REQUESTS is reached the sender or the receiver may use
the Abort frames. When the receiver needs to abort the on-going
fragmented packet transmission, it uses the ACK Abort format
packet with all the bits set to 1. The sender will use the All-1
Abort format to trigger the end of the transmission.
o Padding (P). Padding will be used to align the last byte of a
fragment with a byte boundary. The number of bits used for
padding is not defined and depends on the size of the Rule ID,
DTag and FCN fields, and on the layer two payload size.
5.3. Delivery Reliability options
This specification defines the following three fragment delivery This specification defines the following three fragment delivery
reliability options: reliability options:
o No ACK. No ACK is the simplest fragment delivery reliability o No ACK. No ACK is the simplest fragment delivery reliability
option. The receiver does not generate overhead in the form of option. The receiver does not generate overhead in the form of
acknowledgments (ACKs). However, this option does not enhance acknowledgments (ACKs). However, this option does not enhance
delivery reliability beyond that offered by the underlying LPWAN delivery reliability beyond that offered by the underlying LPWAN
technology. In the No ACK option, the receiver MUST NOT issue ACKs. technology. In the No ACK option, the receiver MUST NOT issue
ACKs.
o Window mode - ACK always (ACK-always). o Window mode - ACK always (ACK-always).
The ACK-always option provides flow control. In addition, it is able The ACK-always option provides flow control. In addition, this
to handle long bursts of lost fragments, since detection of such option is able to handle long bursts of lost fragments, since
events can be done before the end of the IPv6 packet transmission, as detection of such events can be done before the end of the IPv6
long as the window size is short enough. However, such benefit comes packet transmission, as long as the window size is short enough.
at the expense of ACK use. In ACK-always, an ACK is transmitted by However, such benefit comes at the expense of ACK use. In ACK-
the fragment receiver after a window of fragments have been sent. A always, an ACK is transmitted by the fragment receiver after a
window of fragments is a subset of the full set of fragments needed window of fragments has been sent. A window of fragments is a
to carry an IPv6 packet. In this mode, the ACK informs the sender subset of the full set of fragments needed to carry an IPv6
about received and/or missed fragments from the window of fragments. packet. In this mode, the ACK informs the sender about received
Upon receipt of an ACK that informs about any lost fragments, the and/or missed fragments from the window of fragments. Upon
sender retransmits the lost fragments. When an ACK is not received receipt of an ACK that informs about any lost fragments, the
by the fragment sender, the latter retransmits an all-1 empty sender retransmits the lost fragments. When an ACK is not
fragment, which serves as an ACK request. The maximum number of ACK received by the fragment sender, the latter sends an ACK request
requests is MAX_ACK_REQUESTS. The default value of MAX_ACK_REQUESTS using the All-1 empty fragment.
is not stated in this document, and it is expected to be defined in
other documents (e.g. technology- specific profiles).
o Window mode - ACK-on-error. The ACK-on-error option is suitable The maximum number of ACK requests is MAX_ACK_REQUESTS.
for links offering relatively low L2 data unit loss probability.
This option reduces the number of ACKs transmitted by the fragment o Window mode - ACK-on-error (ACK-on-error). The ACK-on-error
receiver. This may be especially beneficial in asymmetric scenarios, option is suitable for links offering relatively low L2 data unit
e.g. where fragmented data are sent uplink and the underlying LPWAN loss probability. This option reduces the number of ACKs
technology downlink capacity or message rate is lower than the uplink transmitted by the fragment receiver. This may be especially
one. However, if an ACK is lost, the sender assumes that all beneficial in asymmetric scenarios, e.g. where fragmented data are
fragments covered by the ACK have been successfully delivered. And sent uplink and the underlying LPWAN technology downlink capacity
the receiver will abort the fragmentation. or message rate is lower than the uplink one.
In ACK-on-error, an ACK is transmitted by the fragment receiver after In ACK-on-error, an ACK is transmitted by the fragment receiver
a window of fragments has been sent, only if at least one of the after a window of fragments have been sent, only if at least one
fragments in the window has been lost. In this mode, the ACK informs of the fragments in the window has been lost. In this mode, the
the sender about received and/or missed fragments from the window of ACK informs the sender about received and/or missed fragments from
fragments. Upon receipt of an ACK that informs about any lost the window of fragments. Upon receipt of an ACK that informs
fragments, the sender retransmits the lost fragments. about any lost fragments, the sender retransmits the lost
fragments. However, if an ACK is lost, the sender assumes that
all fragments covered by the ACK have been successfully delivered.
And the receiver will abort the on-going fragmented packet
transmission. One exception to this behavior is in the last
window, whete the receiver MUST transmit an ACK, even if all the
fragments in the last window have been correctly received.
The same reliability option MUST be used for all fragments of a The same reliability option MUST be used for all fragments of a
packet. It is up to implementers and/or representatives of the packet. It is up to implementers and/or representatives of the
underlying LPWAN technology to decide which reliability option to use underlying LPWAN technology to decide which reliability option to use
and whether the same reliability option applies to all IPv6 packets and whether the same reliability option applies to all IPv6 packets
or not. Note that the reliability option to be used is not or not. Note that the reliability option to be used is not
necessarily tied to the particular characteristics of the underlying necessarily tied to the particular characteristics of the underlying
L2 LPWAN technology (e.g. the No ACK reliability option may be used L2 LPWAN technology (e.g. the No ACK reliability option may be used
on top of an L2 LPWAN technology with symmetric characteristics for on top of an L2 LPWAN technology with symmetric characteristics for
uplink and downlink). uplink and downlink).
This document does not make any decision as to which fragment This document does not make any decision as to which fragment
delivery reliability option(s) are supported by a specific LPWAN delivery reliability option(s) are supported by a specific LPWAN
technology. technology.
Examples of the different reliability options described are provided Examples of the different reliability options described are provided
in Appendix A. in Appendix B.
5.3. Functionalities
This subsection describes the different fields in the fragmentation
header that are used to enable the described fragmentation
functionalities and the different reliability options supported.
o Rule ID. The Rule ID in the fragmentation part is used to identify
the fragmentation mode used, also to idenitfy fragments from ACK and
Abort frames. The also allows to interleave non-fragmented IPv6
datagrams with fragments that carry a larger IPv6 datagram. In the
fragments format this field has a size of R - T - N - 1 bits when
Window mode is used. In No ACK mode, the Rule ID field has a size of
R - T - N bits see format section.
o Fragment Compressed Number (FCN). The FCN is included in all
fragments. This field can be understood as a truncated, efficient
representation of a larger-sized fragment number, and does not carry
an absolute fragment number. There are two reserved values used for
the control of the fragmentation. The FCN value when all the bits
equals 1 (all-1) denotes the last fragment of a packet. And the FCN
value when all the bits equals 0 (all-0) denotes the last fragment of
the windonw in any window mode or the fragments in No ACK mode. The
rest of the FCN values are used in a sequential and decreasing order,
which has the purpose to avoid possible ambiguity for the receiver
that might arise under certain conditions. In the fragments, this
field is an unsigned integer, with a size of N bits. In the No ACK
mode it is set to 1 bit (N=1). For the other modes it is recommended
to use a number of bits (N) equal to or greater than 3. The FCN MUST
be set sequentially
decreasing from the highest FCN in the window (which will be used for
the first fragment), and MUST wrap from 0 back to the highest FCN in
the window.
The FCN for the last fragment in a window is an all-0, which
indicates that the window is finished and it proceeds according to
the mode in use: either an ack is sent or the next window fragments
are expected when there is no error. The FCN for the last fragment
is an all-1. It is also important to note that, for No ACK mode or
N=1, the last fragment of the packet will carry a FCN equal to 1,
while all previous fragments will carry a FCN of 0.
o Datagram Tag (DTag). The DTag field, if present, is set to the
same value for all fragments carrying the same IPv6 datagram, allows
to interleave fragments that correspond to different IPv6 datagrams.
In the fragment formats the size of the DTag field is T bits, which
may be set to a value greater than or equal to 0 bits. DTag MUST be
set sequentially increasing from 0 to 2^T - 1, and MUST wrap back
from 2^T - 1 to 0. In the ACK format, DTag carries the same value as
the DTag field in the fragments for which this ACK is intended.
o W (window): W is a 1-bit field. This field carries the same value
for all fragments of a window, and it is complemented for the next
window. The initial value for this field is 0. In the ACK format,
this field has a size of 1 bit. In all ACKs, the W bit carries the
same value as the W bit carried by the fragments whose reception is
being positively or negatively acknowledged by the ACK.
o Message Integrity Check (MIC). This field, which has a size of M
bits. It is computed by the sender over the complete packet (i.e. a
SCHC compressed or an uncompressed IPv6 packet) before fragmentation.
The algorithm to be used to compute the MIC is not defined in this
document, and needs to be defined in other documents (e.g.
technology-specific profiles). The MIC allows the receiver to check
errors in the reassembled packet, while it also enables compressing
the UDP checksum by use of SCHC compression.
o Bitmap. The bitmap is a sequence of bits included in the ACK for a
given window, each bit in the Bitmap identifies a fragment. It
provides feedback on whether each fragment of the current window has
been received or not. FCN set to All-0 and All-1 fragments are set
to the right-most position on the bitmap in this order. Highest FCN
is set to the left-most position. A bit set to 1 indicates that the
corresponding FCN fragment has been correctly sent and received.
TODO (it is missing to explain the optimization of bitmap in order to
have a way to send an abort)
5.4. Formats 5.4. Fragmentation Frames Formats
This section defines the fragment format, the fragmentation header This section defines the fragment format, the All-0 and All-1 frames
formats, and the ACK format. format, the ACK format and the Abort frames format.
5.4.1. Fragment format 5.4.1. Fragment format
A fragment comprises a fragmentation header and a fragment payload, A fragment comprises a fragmentation header, a fragment payload, and
and conforms to the format shown in Figure 6. The fragment payload Padding bits (if any). A fragment conforms to the format shown in
carries a subset of either a SCHC header or an IPv6 header or the Figure 6. The fragment payload carries a subset of either a SCHC
original IPv6 packet payload which could not be compressed. A header or an IPv6 header or the original IPv6 packet data payload. A
fragment is the payload in the L2 protocol data unit (PDU). fragment is the payload in the L2 protocol data unit (PDU).
+---------------+-----------------------+ +-----------------+-----------------------+---------+
| Fragm. Header | Fragment payload | | Fragment Header | Fragment payload | padding |
+---------------+-----------------------+ +-----------------+-----------------------+---------+
Figure 6: Fragment format. Figure 6: Fragment format.
5.4.2. Fragmentation header formats 5.4.2. Fragmentation formats
In the No ACK option, fragments except the last one SHALL contain the In the No ACK option, fragments except the last one SHALL contain the
fragmentation header as defined in Figure 7. The total size of this format as defined in Figure 7. The total size of the fragmentation
fragmentation header is R bits. header is R bits.
<------------ R ----------> <------------ R ---------->
<--T--> <--N--> <--T--> <--N-->
+-- ... --+- ... -+- ... -+---...---+ +-- ... --+- ... -+- ... -+---...---+-+
| Rule ID | DTag | FCN | payload | | Rule ID | DTag | FCN | payload |P|
+-- ... --+- ... -+- ... -+---...---+ +-- ... --+- ... -+- ... -+---...---+-+
Figure 7: Fragmentation Header for Fragments except the Last One, No Figure 7: Fragmentation Format for Fragments except the Last One, No
ACK option ACK option
In any of the Window mode options, fragments except the last one In any of the Window mode options, fragments except the last one
SHALL contain the fragmentation header as defined in Figure 8. The SHALL contain the fragmentation format as defined in Figure 8. The
total size of this fragmentation header is R bits. total size of this fragmentation header is R bits.
<------------ R ----------> <------------ R ---------->
<--T--> 1 <--N--> <--T--> 1 <--N-->
+-- ... --+- ... -+-+- ... -+---...---+ +-- ... --+- ... -+-+- ... -+---...---+-+
| Rule ID | DTag |W| FCN | payload | | Rule ID | DTag |W| FCN | payload |P|
+-- ... --+- ... -+-+- ... -+---...---+ +-- ... --+- ... -+-+- ... -+---...---+-+
Figure 8: Fragmentation Header for Fragments except the Last One, Figure 8: Fragmentation Format for Fragments except the Last One,
Window mode Window mode
5.4.3. ACK format 5.4.3. ACK format
The format of an ACK is shown in Figure 9: The format of an ACK that acknowledges a window that is not the last
one (denoted as ALL-0 window) is shown in Figure 9.
<-------- R -------> <-------- R ------->
<- T -> 1 <- T -> 1
+---- ... --+-... -+-+----- ... ---+ +---- ... --+-... -+-+----- ... ---+
| Rule ID | DTag |W| bitmap | | Rule ID | DTag |W| bitmap | (no payload)
+---- ... --+-... -+-+----- ... ---+ +---- ... --+-... -+-+----- ... ---+
Figure 9: Format of an ACK Figure 9: ACK format for All-0 windows
Figure 10 shows an example of an ACK (N=3), where the bitmap
indicates that the second and the fifth fragments have not been
correctly received.
<------- R -------> To acknowledge the last window of a packet (denoted as All-1 window),
<- T -> 1 6 5 4 3 2 1 0 a C bit (i.e. MIC checked) following the W bit is set to 1 to
+---- ... --+-... -+-+-+-+-+-+-+-+-----+ indicate that the MIC check computed by the receiver matches the MIC
| Rule ID | DTag |W|1|0|1|1|0|1|all-0| TODO present in the ALL-1 fragment. If the MIC check fails, the C bit is
+---- ... --+-... -+-+-+-+-+-+-+-+-----+ set to 0 and the Bitmap for the All-1 window follows.
Figure 10: Example of the bitmap in Window mode, in any window unless <-------- R -------> <- byte boundary ->
the last one, for N=3) <- T -> 1 1
+---- ... --+-... -+-+-+
| Rule ID | DTag |W|1| (MIC correct)
+---- ... --+-... -+-+-+
<------- R -------> +---- ... --+-... -+-+-+------- ... -------+
<- T -> 1 6 5 4 3 2 1 7 | Rule ID | DTag |W|0| bitmap | (MIC Incorrect)
+---- ... --+-... -+-+-+-+-+-+-+-+-----+ +---- ... --+-... -+-+-+------- ... -------+
| Rule ID | DTag |W|1|0|1|1|0|1|all-1| TODO C
+---- ... --+-... -+-+-+-+-+-+-+-+-----+
Figure 11: Example of the bitmap in Window mode for the last window, Figure 10: Format of an ACK for All-1 windows
for N=3)
5.4.4. All-1 and All-0 formats 5.4.4. All-1 and All-0 formats
The All-0 format is used for the last fragment of a window that is
not the last window of the packet.
<------------ R ------------> <------------ R ------------>
<- T -> 1 <- N -> <- T -> 1 <- N ->
+-- ... --+- ... -+-+- ... -+--- ... ---+ +-- ... --+- ... -+-+- ... -+--- ... ---+
| Rule ID | DTag |W| 0..0 | payload | TODO | Rule ID | DTag |W| 0..0 | payload |
+-- ... --+- ... -+-+- ... -+--- ... ---+ +-- ... --+- ... -+-+- ... -+--- ... ---+
Figure 12: All-0 format fragment Figure 11: All-0 fragment format
In the No ACK option, the last fragment of an IPv6 datagram SHALL The All-0 empty fragment format is used by a sender to request an ACK
contain a fragmentation header that conforms to the format shown in in ACK-Always mode
Figure 14. The total size of this fragmentation header is R+M bits. <------------ R ------------>
<- T -> 1 <- N ->
+-- ... --+- ... -+-+- ... -+
| Rule ID | DTag |W| 0..0 | (no payload)
+-- ... --+- ... -+-+- ... -+
<------------ R ------------> Figure 12: All-0 empty fragment format
<- T -> 1 <- N ->
+-- ... --+- ... -+-+- ... -+
| Rule ID | DTag |W| 0..0 | TODO
+-- ... --+- ... -+-+- ... -+
Figure 13: All-0 empty format fragment In the No ACK option, the last fragment of an IPv6 datagram SHALL
contain a fragmentation header that conforms to the format shown in
Figure 13. The total size of this fragmentation header is R+M bits.
<------------- R ----------> <------------- R ---------->
<- T -> <-N-><----- M -----> <- T -> <-N-><----- M ----->
+---- ... ---+- ... -+-----+---- ... ----+---...---+ +---- ... ---+- ... -+-----+---- ... ----+---...---+
| Rule ID | DTag | 1 | MIC | payload | | Rule ID | DTag | 1 | MIC | payload |
+---- ... ---+- ... -+-----+---- ... ----+---...---+ +---- ... ---+- ... -+-----+---- ... ----+---...---+
Figure 14: All-1 Fragmentation Header for the Last Fragment, No ACK Figure 13: All-1 Fragmentation Format for the Last Fragment, No ACK
option option
In any of the Window modes, the last fragment of an IPv6 datagram In any of the Window modes, the last fragment of an IPv6 datagram
SHALL contain a fragmentation header that conforms to the format SHALL contain a fragmentation header that conforms to the format
shown in Figure 15. The total size of this fragmentation header is shown in Figure 14. The total size of the fragmentation header in
R+M bits. It is used for retransmissions this format is R+M bits. It is used for request a retransmission
<------------ R ------------> <------------ R ------------>
<- T -> 1 <- N -> <---- M -----> <- T -> 1 <- N -> <---- M ----->
+-- ... --+- ... -+-+- ... -+---- ... ----+---...---+ +-- ... --+- ... -+-+- ... -+---- ... ----+---...---+
| Rule ID | DTag |W| 11..1 | MIC | payload | | Rule ID | DTag |W| 11..1 | MIC | payload |
+-- ... --+- ... -+-+- ... -+---- ... ----+---...---+ +-- ... --+- ... -+-+- ... -+---- ... ----+---...---+
(FCN) (FCN)
Figure 15: All-1 Fragmentation Header for the Last Fragment, Window Figure 14: All-1 Fragmentation Format for the Last Fragment, Window
mode mode
The values for R, N, T and M are not specified in this document, and In either ACK-Always or ACK-on-error, in order to request a
have to be determined in other documents (e.g. technology-specific retransmission of the ACK for the All-1 window, the fragment sender
profile documents). uses the format shown in Figure 15. The total size of the
fragmentation header in this format is R+M bits.
<------------ R ------------> <------------ R ------------>
<- T -> 1 <- N -> <---- M -----> <- T -> 1 <- N -> <---- M ----->
+-- ... --+- ... -+-+- ... -+---- ... ----+ +-- ... --+- ... -+-+- ... -+---- ... ----+
| Rule ID | DTag |W| 1..1 | MIC | (no payload) TODO | Rule ID | DTag |W| 1..1 | MIC | (no payload)
+-- ... --+- ... -+-+- ... -+---- ... ----+ +-- ... --+- ... -+-+- ... -+---- ... ----+
Figure 16: All-1 for Retries format fragment also called All-1 empty Figure 15: All-1 for Retries format fragment also called All-1 empty
<------------ R ------------> The values for R, N, T and M are not specified in this document, and
<- T -> 1 <- N -> have to be determined in other documents (e.g. technology-specific
+-- ... --+- ... -+-+- ... -+ profile documents).
| Rule ID | DTag |W| 11..1 | (no MIC and no payload) TODO
+-- ... --+- ... -+-+- ... -+
Figure 17: All-1 for Abort format fragment 5.4.5. Abort formats
The All-1 Abort format and the ACK abort have the following formats.
<------ byte boundary ------><--- 1 byte --->
+--- ... ---+- ... -+-+-...-+-+-+-+-+-+-+-+-+
| Rule ID | DTag |W| FCN | FF | (no MIC & no payload)
+--- ... ---+- ... -+-+-...-+-+-+-+-+-+-+-+-+
Figure 16: All-1 Abort format
<------ byte boundary -----><--- 1 byte --->
<----- Complete Byte ------><--- 1 byte --->
<------- R ------->
<- T -> 1
+---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+ +---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule ID | DTag |W| 1..1| FF | TODO | Rule ID | DTag |W| 1..1| FF |
+---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+ +---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: ACK Abort format fragment Figure 17: ACK Abort format
5.5. Baseline mechanism 5.5. Baseline mechanism
The receiver needs to identify all the fragments that belong to a The fragment receiver needs to identify all the fragments that belong
given IPv6 datagram. To this end, the receiver SHALL use: * The to a given IPv6 datagram. To this end, the receiver SHALL use:
sender's L2 source address (if present), * The destination's L2
address (if present), * Rule ID and * DTag (the latter, if present). o The sender's L2 source address (if present),
o The destination's L2 address (if present),
o Rule ID and
o DTag (the latter, if present).
Then, the fragment receiver may determine the fragment delivery Then, the fragment receiver may determine the fragment delivery
reliability option that is used for this fragment based on the Rule reliability option that is used for this fragment based on the Rule
ID field in that fragment. ID field in that fragment.
Upon receipt of a link fragment, the receiver starts constructing the Upon receipt of a link fragment, the receiver starts constructing the
original unfragmented packet. It uses the FCN and the order of original unfragmented packet. It uses the FCN and the order of
arrival of each fragment to determine the location of the individual arrival of each fragment to determine the location of the individual
fragments within the original unfragmented packet. A fragment fragments within the original unfragmented packet. A fragment
payload may carry bytes from a SCHC compressed IPv6 header, an payload may carry bytes from a SCHC compressed IPv6 header, an
uncompressed IPv6 header or an IPv6 datagram data payload. An uncompressed IPv6 header or an IPv6 datagram data payload. An
unfragmented packet could be a SCHC compressed or an uncompressed unfragmented packet could be a SCHC compressed or an uncompressed
IPv6 packet (header and data). For example, the receiver may place IPv6 packet (header and data). For example, the receiver may place
the fragment payload within a payload datagram reassembly buffer at the fragment payload within a payload datagram reassembly buffer at
the location determined from: the FCN, the arrival order of the the location determined from: the FCN, the arrival order of the
fragments, and the fragment payload sizes. In Window mode, the fragments, and the fragment payload sizes. In Window mode, the
fragment receiver also uses the W bit in the received fragments. fragment receiver also uses the W bit in the received fragments.
Note that the size of the original, unfragmented packet cannot be Note that the size of the original, unfragmented packet cannot be
determined from fragmentation headers. determined from fragmentation headers.
Note that, in Window mode, the first fragment of the window is the Fragmentation functionality uses the FCN value, which has a length of
one with FCN set to MAX_WIND_FCN. Also note that, in Window mode, N bits. The All-1 and All-0 FCN values are used to control the
the fragment with all-0 is considered the last fragment of its fragmentation transmission. The FCN will be assigned sequentially in
window, except for the last fragment of the whole packet (all-1), a decreasing order starting from 2^N-2, i.e. the highest possible FCN
which is also the last fragment of the last window. value depending on the FCN number of bits, but excluding the All-1
value. In all modes, the last fragment of a packet must contains a
MIC which is used to check if there are errors or missing fragments,
and must use the corresponding All-1 fragment format. Also note
that, a fragment with an All-0 format is considered the last fragment
of the current window.
If the recipient receives the last fragment of a datagram (all-1), it If the recipient receives the last fragment of a datagram (All-1), it
checks for the integrity of the reassembled datagram, based on the checks for the integrity of the reassembled datagram, based on the
MIC received. In No ACK, if the integrity check indicates that the MIC received. In No ACK, if the integrity check indicates that the
reassembled datagram does not match the original datagram (prior to reassembled datagram does not match the original datagram (prior to
fragmentation), the reassembled datagram MUST be discarded. In fragmentation), the reassembled datagram MUST be discarded. In
Window mode, a MIC check is also performed by the fragment receiver Window mode, a MIC check is also performed by the fragment receiver
after reception of each subsequent fragment retransmitted after the after reception of each subsequent fragment retransmitted after the
first MIC check. In ACK always, if a MIC check indicates that the first MIC check.
datagram has been successfully reassembled, the fragment receiver
sends an ACK without a bitmap to the fragment sender.
If a fragment recipient disassociates from its L2 network, the
recipient MUST discard all link fragments of all partially
reassembled payload datagrams, and fragment senders MUST discard all
not yet transmitted link fragments of all partially transmitted
payload (e.g., IPv6) datagrams. Similarly, when either end of the
LPWAN link first receives a fragment of a packet, it starts a
reassembly timer. When this time expires, if the entire packet has
not been reassembled, the existing fragments MUST be discarded and
the reassembly state MUST be flushed. The value for this timer is
not provided by this specification, and is expected to be defined in
technology-specific profile documents.
TODO (explain the Bitmap optimization)
5.6. Supporting multiple window sizes
For Window mode operation, implementers may opt to support a single
window size or multiple window sizes. The latter, when feasible, may
provide performance optimizations. For example, a large window size
may be used for packets that need to be carried by a large number of
fragments. However, when the number of fragments required to carry
an packet is low, a smaller window size, and thus a shorter bitmap,
may be sufficient to provide feedback on all fragments. If multiple
window sizes are supported, the Rule ID may be used to signal the
window size in use for a specific packet transmission.
TODO (does it works for ACK-on-error?)
5.7. Aborting fragmented datagram transmissions
For several reasons, a fragment sender or a fragment receiver may
want to abort the on-going transmission of one or several fragmented
IPv6 datagrams.
TODO (explain the abort format packets)
Upon transmission or reception of the abortion signal, both entities
MUST release any resources allocated for the fragmented datagram
transmissions being aborted.
5.8. Downlink fragment transmission
In some LPWAN technologies, as part of energy-saving techniques,
downlink transmission is only possible immediately after an uplink
transmission. In order to avoid potentially high delay for
fragmented datagram transmission in the downlink, the fragment
receiver MAY perform an uplink transmission as soon as possible after
reception of a fragment that is not the last one. Such uplink
transmission may be triggered by the L2 (e.g. an L2 ACK sent in
response to a fragment encapsulated in a L2 frame that requires an L2
ACK) or it may be triggered from an upper layer.
5.9. Fragmentation Mode of Operation Description
The fragmentation is based on the FCN value, which has a length of N
bits. The All-1 and All-0 values are reserved, and are used to
control the fragmentation transmission. The FCN will be sent in
downwards position this means from larger to smaller and the number
of bits depends on the implementation. The last fragment in all
modes must contains a MIC which is used to check if there are error
or missing fragments.
5.9.1. No ACK Mode
In the No ACK mode there is no feedback communication. The sender
will send the fragments until the last one whithout any possibility
to know if there were an error or lost. As there is not any control
one bit FCN is used, where FCN all-0 will be sent for all the
fragments except the last one which will use FCN to all-1 and will
send the MIC. Figure 19 shows the state machine for the sender.
+-----------+ 5.5.1. No ACK
+------------+ Init |
| FCN=0 +-----------+
| No Window
| No Bitmap
| +-------+
| +--------+--+ | More Fragments
| | | <--+ ~~~~~~~~~~~~~~~~~~~~
+--------> | Send | send Fragment (FCN=0)
+---+-------+
| last fragment
| ~~~~~~~~~~~~
| FCN = 1
v send fragment+MIC
+------------+
| END |
+------------+
Figure 19: Sender State Machine for the No ACK Mode In the No ACK mode there is no feedback communication from the
fragment receiver. The sender will send the fragments of a packet
until the last one without any possibility to know if errors or a
losses have occurred. As in this mode there is not a need to
identify specific fragments a one-bit FCN is used, therefore FCN
All-0 will be used in all fragments except the last one. The latter
will carry an All-1 FCN and will also carry the MIC. The receiver
will wait for fragments and will set the Inactivity timer. The No
ACK mode will use the MIC contained in the last fragment to check
error. When the Inactivity Timer expires or when the MIC check
indicates that the reassembled packet does not match the originall
one, the receiver will release all resources allocated to reassembly
of the packet. The initial value of the Inactivity Timer will be
determined based on the characteristics of the underlying LPWAN
technology and will be defined in other documents (e.g. technology-
specific profile documents).
The receiver waits for fragments and will set a timer in order to see 5.5.2. The Window modes
if there is no missing fragments. The No ACK mode will use the MIC
contained in the last fragment to check error. The FCN is set to
all-1 for the last fragment. Figure 20 shows the state machine for
the receiver. When the Timer expires or when the check of MIC gives
an error it will abort the communication and go to error state, all
the fragments will be dropped. The Inactivity Timer will be based on
the LPWAN technology and will be defined in the specific technology
document.
+------+ Not All-1 In Window modes, a jumping window protocol is using two windows
+----------+-+ | ~~~~~~~~~~~~~~~~~~~ alternatively, 0 and 1. An FCN set to All-0 indicates that the
| + <--+ set Inactivity Timer window is over (i.e. the fragment is the last one of the window) and
| RCV Frag +-------+ allows to switch from one window to another. The All-1 FCN in a
+-+---+------+ |All-1 & fragment indicates that it is the last fragment of the packet and
All-1 & | | |MIC correct therefore there will not be another window for the packet.
MIC wrong | |Inactivity |
| |Timer Exp. |
v | |
+----------++ | v
| Error |<-+ +--------+--+
+-----------+ | END |
+-----------+
Figure 20: Receiver State Machine for the No ACK Mode The Window mode offers two different reliability options modes: ACK-
on-error and ACK-always.
5.9.2. The Window modes 5.5.2.1. ACK-Always
The jumping window protocol is using two windows alternatively 0 and The sender starts sending fragments using the two windows procedure.
1. The FCN to all-0 fragment means that the window is over and A delay between each fragment can be added to respect regulation
allows to switch from one window to another. The FCN to all-1 rules or constraints imposed by the applications. Each time a
fragment indicates that it is the last fragment and there will not be fragment is sent the FCN is decreased by one and the sending
another window. information is set locally. When the FCN reaches value 0 and there
are more fragments to be sent, an All-0 fragment is sent and the
retransmission timer is set. The sender waits for an ACK to know if
there were some transmission errors. If there are some errors the
receiver sends an ACK with the corresponding errors in the Bitmap,
otherwise, an ACK without Bitmap will be sent and a new window should
be sent. When the last fragment is sent, and All-1 fragment with MIC
is sent. The sender sets the retransmission timer to wait for the
ACK corresponding to the last window. During this period, the sender
starts listening to the radio and starts an Inactivity timer, which
is dimensioned based on the received window available for the LPWAN
technology in use. If the Inactivity timer expires an empty All-0
(or All-1 if the last fragment has been sent) fragment is sent to ask
the receiver to resend its ACK. The window number is not changed.
In all the cases, the sender may not have to send all the fragments When the sender receives an ACK, it checks the window value. The ACK
contained in the window. To ease FN (fragment number) reconstruction fragments carrying an unexpected W bit are discarded. If the window
from FCN, it is recommended to send sequentially all the fragments on number of the received ACK is correct, the sender compares the
a window and for all non-terminating window to fill entirely the sending information with the received Bitmap. If the sending
window. information is equal to the received Bitmap all the fragments sent
during the window have been well received. If at least one fragment
needs to be sent, the sender moves its sending window to the next
value and sends the last fragment. If no more fragments have to be
sent, then the fragmented packet transmission is finished.
The receiver generates the bitmap which may have the size of a single If some fragments are missing (not set in the Bitmap) then the sender
frame based on the size of downlink frame of the LPWAN technology resends the missing fragments. When the retransmission is finished,
used. When the bitmap cannot be sent in one frame or for the last it starts the retransmission timer (even if an All-0 or an All-1 has
window, not been sent during the retransmission) and waits for ACK.
, then first the FCN should be set to the lowest possible value. If the sending information is different from the received Bitmap the
counter Attempts is increased and the sender resends the missing
fragments again when a MAX_ACK_REQUESTS is reached, the sender sends
an Abort and drops the fragments. The sender Aborts the transmission
when a corrupt MIC has been received or when MAX_ACK_REQUESTS has
reached.
The Window mode has two different mode of operation: The ACK on error At the beginning, the receiver side expects to receive window 0. Any
and the ACK always. fragment not belonging to the current window is discarded. All
Fragments belonging to the correct window are accepted, the fragment
number is computed based on the FCN value. The receiver updates the
Bitmap with the correct received fragments.
5.9.3. ACK Always When All-0 fragment is received, it indicates that all the fragments
have been sent in the current window. Since the sender is not
obliged to send a full window, some fragment number not set in the
memory may not correspond to losses. It sends the corresponding ACK
and the next window can start.
The Figure 21 finite state machine describes the sender behavior. When All-1 fragment is received, it indicates that the transmission
Intially, when a fragmented packet need to be sent, the window is set is finished. Since the last window is not full, the MIC will be used
to 0, a local_bit map is set to 0, and FCN is set the the highest to detect if all the fragments have been received. A correct MIC
possible value depending on the number of fragment that will be sent indicates the end of the transmission but the receiver must stay
in the window (INIT STATE). alive an Inactivity timer period to answer to empty All-1 fragment
the sender may send if the ACK is lost.
The sender starts sending fragments (SEND STATE), the sender will If All-1 fragment has not been received, the receiver expects a new
indicate in the fragmentation header: the current window and the FCN window. It waits for the next fragment. If the window value has not
number. A delay between each fragment can be added to respect changed, the received fragments are part of a retransmission. A
regulation rules or constraints imposed by the applications. Each receiver that has already received a fragment should discard it,
time a fragment is sent the FCN is decreased of one value and the otherwise, it updates the Bitmap. If all the bits of the Bitmap are
bitmap is set. The send state can be leaved for different reasons set to one, the receiver may send an ACK without waiting for an All-0
(for both reasons it goes to WAIT BITMAP STATE): fragment.
o The FCN reaches value 0 and there are more fragments. In that If the window value is set to the next value, this means that the
case an all-0 fragmet is sent and the timer is set. The sender sender has received a correct bitmap, which means that all the
will wait for the bitmap acknowledged by the receiver. fragments have been received. The receiver changes the value of the
expected window.
o The last fragment is sent. In that case an all-1 fragment with If the receiver receives an All-0 fragment, the sender may send one
the MIC is sent and the sender will wait for the bitmap or more fragments per window. Otherwise, some fragments in the
acknowledged by the receiver. The sender set a timer to wait for window have been lost.
the ack.
During the transition between the SEND state of the current window If the receiver receives an All-1 fragment this means that the
and the WAIT BITMAP, the sender start listening to the radio and transmission should be finished. If the MIC is incorrect some
start a timer. This timer is dimensioned to the receiving window fragments have been lost. It sends the ACK. In case of an incorrect
depending on the LPWAN technology. MIC, the receivers wait for fragments belonging to the same window.
After MAX_ACK_REQUESTS the receiver will Abort the transmission. It
can also Abort when the Inactivity timer has expired.
In ACK Always, if the timer expire, an empty All-0 (or All-1 if the 5.5.2.2. ACK-on-error
last fragment has been sent) fragment is sent to ask the receiver to
resent its bitmap. The window number is not changed.
The sender receives a bitmap, it checks the window value. The ACK-on-error is similar to the ACK-Always procedure, the
Acknowledgment with the non expected window are discarded. difference is that in ACK-on-error the ACK is not sent at the end of
each window but only when there is an error. In Ack-on-error mode,
the retransmission timer expiration will be considered as a positive
acknowledgment, it is set when receiving an All-0 or an All-1
fragment. If there are no more fragments then the fragmentation is
finished.
If the window number on the received bitmap is correct, the sender When the All-1 last fragment is sent and the correct MIC have been
compares the local bitmap with the received bitmap. If they are received an ACK is sent to confirms the end of the correct
equal all the fragments sent during the window have been well transmission. If the retransmission timer expires an All-1 empty
received. If at least one fragment need to be sent, the sender clear request the last ACK that MUST be sent to complete the fragmentation
the bitmap, stop the timer and move its sending window to the next transmission.
value. If no more fragments have to be sent, then the fragmented
packet transmission is terminated.
If some fragments are missing (not set in the bit map) then the If the sender receives an ACK, it checks the window value. ACKs with
sender resend the missing fragments. When the retransmission is the non-expected window number are discarded. If the window number
finished, it start listening to the bitmap (even if a All-0 or All-1 on the received Bitmap is correct, the sender verifies if the
has not been sent during the retransmission) and returns to the receiver has all the fragments. When all the fragments have been
waiting bitmap state. received the transmission of a new window should continue.
Otherwise, when there is an error the counter Attempts is increased
and the sender resends the missing fragments again. When a
MAX_ACK_REQUESTS is reached, the sender sends an Abort. When the
retransmission is finished, it starts listening to the ACK (even if
an All-0 or an All-1 has not been sent during the retransmission) and
set the retransmission timer. If the retransmission timer expires
the transmission is aborted.
If the local-bitmap is different from the received bitmap the counter Unlike the sender, the receiver for ACK-on-error has some
Attemps is increased and the sender resend the missing fragments differences. First, we are not sending ACK unless there is an error
again, when a MAX_ATTEMPS is reached the sender sends an Abort and or an unexpected behavior. The receiver starts with the expected
goes to error. window and maintains the information indicating which fragments it
has received (All-0 and All-1 occupy the same position). After
receiving a fragment an Inactivity timer is set, if nothing has been
received and the Inactivity timer expires the transmission is
aborted.
+-------+ Any fragment not belonging to the current window is discarded. The
| INIT | FCN!=0 & more frags Fragment Number is computed based on the FCN value. When an All-0
| | ~~~~~~~~~~~~~~~~~~~~~~ fragment is received and the Bitmap is full, the receiver changes the
+------++ +--+ send Window + frag(FCN) window value.
W=0 | | | FCN-
Clear local bitmap | | v set local bitmap
FCN=max value | ++--+--------+
+> | |
+---------------------> | SEND |
| +--+-----+---+
| FCN==0 & more frags | | last frag
| ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~
| set local-bitmap | | set local-bitmap
| send wnd + frag(all-0) | | send wnd+frag(all-1)+MIC
| set Timer | | set Timer
| | |
|Recv_wnd == wnd & | |
|Lcl_bitmap==recv_bitmap& | | +-------------------------+
|more frag | | |local-bitmap!=rcv-bitmap |
|~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ |
|Stop Timer | | | Attemp++ v
|clear local_bitmap v v | +------++
|window=next_window +----+-----+--+--+ |Resend |
+---------------------+ | |Missing|
+----+ Wait | |Frag |
not expected wnd | | bitmap | +------++
~~~~~~~~~~~~~~~~ +--->+ +---+ Timer Exp |
discard frag +--+---+---+---+-+ |~~~~~~~~~~~~~~~~~ |
| | ^ ^ |Snd(empty)frag(0) |
| | | | |Set Timer |
| | | +-----+ |
Recv_window==window & | | +----------------------------+
Lcl_bitmap==recv_bitmap &| | all missing frag sent
no more frag| | ~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~| | Set Timer
Stop Timer| |
+-------------+ | |
| +<----+ | MAX_ATTEMPS > limit
| END | | ~~~~~~~~~~~~~~~~~~
| | v Send Abort
+-------------+ +-+-----------+
| ERROR |
+-------------+
Figure 21: Sender State Machine for the ACK Always Mode An All-0 fragment and not a full bitmap indicate that all the
fragments have been sent in the current window. Since the sender is
not obligated to send a full window, some fragment number not used
may not correspond to losses. As the receiver does not know if the
missing fragments are lost or normal missing fragments, it sends an
ACK.
The Figure 22 finite state machine describes the receiver behavior. An All-1 fragment indicates that the transmission is finished. Since
The receiver starts with window 0 as the expecting window and the last window is not full, the MIC will be used to detect if all
maintain a local_bitmap indicating which fragments it has received the fragments have been received. A correct MIC indicates the end of
(all-0 and all-1 occupy the same position). the transmission.
Any fragment not belonging to the current window is discarded. If All-1 fragment has not been received, the receiver expects a new
Fragment belonging to the correct window are accepted, FN is computed window. It waits for the next fragment. If the window value has not
based on the FCN value. The receiver leaves this state when changed, the received fragments are part of a retransmission. A
receiving a: receiver that has already received a fragment should discard it. If
all the bits of the Bitmap are set to one, the receiver waits for the
next window without waiting for an All-0 fragment and it does not
send an ACK either. While the receiver waits for next window and if
the window value is set to the next value, and if an All-1 fragment
with the next value window arrived the receiver goes to error and
abort the transmission, it drops the fragments.
o All-0 fragment which indicates that all the fragments have been If the receiver receives an All-1 fragment this means that the
sent in the current window. Since the sender is not obliged to transmission should be finished. If the MIC is incorrect some
send a full window, some fragment number not set in the fragments have been lost. It sends an ACK.
local_bitmap may not correspond to losses.
o All-1 fragment which indicated that the transmission is finished. In case of an incorrect MIC, the receivers wait for fragment
Since the last window is not full, the MIC will be used to detect belonging to the same window or the expiration of the Inactivity
if all the fragments have been received. timer which will Abort the transmission.
A correct MIC indicates the end of the transmission. The receiver 5.5.3. Bitmap Optimization
must stay in this state during a period of time to answer to empty
all-1 frag the sender may send if the bitmap is lost.
If All-1 frag has not been received, the receiver expect a new The Fragmentation Bitmap is the optmization of what has been
window. It waits for the next fragment. If the window value has not received. It is transmitted in the ACK format fragment when there
changed, the received fragments are part of a retransmission. A are some missing fragments. An ACK message may introduce padding at
receiver that has already received a frag should discard it (not the end to align transmitted data to a byte boundary. The first byte
represented in the state machine), otherwise it completes its bitmap. boundary includes one or more complete bytes, depending on the size
If all the bit of the bitmap are set to one, the receiver may send a of Rule ID and DTag.
bitmap without waiting for a all-0 frag.
If the window value is set to the next value, this means that the The receiver generates the Bitmap which may have the size of a single
sender has received a correct bitmap, which means that all the downlink frame of the LPWAN technology used. To avoid this problem
fragments have been received. The receiver change the value of the the FCN size should be set to the corresponding downlink size minus 1
expected window. bit for C bit. The C bit will be sent only in the ACK for the last
frame of the packet (All-1).
If the receiver receives an all-0 fragment, it stays in the same <---- bitmap fragments ---->
state. Sender may send more one fragment per window or more. | Rule ID | DTag |W|C|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|0|
Otherwise some fragments in the window have been lost. |--- byte boundary ----| 1 byte next | 1 byte next |
If the receiver receives an all-1 fragment this means that the Figure 18: Bitmap
transmission should be finished. If the MIC is incorrect some
fragments have been lost. It sends its bitmap.
In case of an incorrect MIC, the receivers wait for fragment Bitmap transmitted MUST be optimized in size to reduce frame size.
belonging to the same window. The right-most bytes with all Bitmap bit set to 1 MUST be removed
from the transmission. As the receiver knows the Bitmap size, it can
reconstruct the value. In the example Figure 19 the last 2 bytes of
the bitmap are set to 1, therefore, they are not sent.
Not All- & w=expected +---+ +---+w = Not expected In the last window, when checked bit C value is one, means that the
~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ MIC is corrected and the Bitmap is not sent. Otherwise, the Bitmap
Set local_bitmap(FCN) | v v |discard needs to be sent after the C bit. Note that the introduction of a C
++---+---+---+-+ bit may force to reduce the number of fragments to allow the bitmap
+---------------------+ Rcv | to fit in a frame.
| +------------------+ Window |
| | +-----+--+-----+
| | All-0 & w=expect | ^ w =next & not-All
| | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~
| | set lcl_bitmap(FCN)| |expected = next window
| | send local_bitmap | |Clear local_bitmap
| | | |
| | w=expct & not-All | |
| | ~~~~~~~~~~~~~~~~~~ | |
| | set lcl_bitmap(FCN)+-+ | | +--+ w=next & All-0
| | if lcl_bitmap full | | | | | | ~~~~~~~~~~~~~~~
| | send lcl_bitmap v | v | | | expct = nxt wnd
| | +-+-+-+--+-++ | Clear lcl_bitmap
| | w=expected & +->+ Wait +<+ set lcl_bitmap(FCN)
| | All-1 | | Next | send lcl_bitmap
| | ~~~~~~~~~~~~ +--+ Window |
| | discard +--------+-++
| | All-1 & w=next| | All-1 & w=nxt
| | & MIC wrong| | & MIC right
| | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~
| | set local_bitmap(FCN)| |set lcl_bitmap(FCN)
| | send local_bitmap| |send local_bitmap
| | | +----------------------+
| |All-1 & w=expct | |
| |& MIC wrong v +---+ w=expctd & |
| |~~~~~~~~~~~~~~~~~~~~ +----+---+-+ | MIC wrong |
| |set local_bitmap(FCN) | +<+ ~~~~~~~~~~~~~~ |
| |send local_bitmap | Wait End | set lcl_btmp(FCN)|
| +--------------------->+ | |
| +---+----+-+ |
| w=expected & MIC right| |
| ~~~~~~~~~~~~~~~~~~~~~~| +-+ Not All-1 |
| set local_bitmap(FCN)| | | ~~~~~~~~~ |
| send local_bitmap| | | discard |
| | | | |
|All-1 & w=expctd & MIC right | | | +-+ All-1 |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v | v ~~~~~~~~~ |
|set local_bitmap(FCN) +-+-+-+-+-++Send lcl_btmp |
|send local_bitmap | | |
+-------------------------->+ END +<---------------+
++--+------+
Figure 22: Receiver State Machine for the ACK Always Mode <------- R ------->
<- T -> 1
+---- ... --+-... -+-+-+-+
| Rule ID | DTag |W|1|0|
+---- ... --+-... -+-+-+-+
|---- byte boundary -----|
5.9.4. ACK on error Figure 19: Bitmap transmitted fragment format
The ACK on error sender is very similar to the ACK always sender, Figure 20 shows an example of an ACK (N=3), where the Bitmap
Intially, when a fragmented packet is sent, the window is set to 0, a indicates that the second and the fifth fragments have not been
local_bit map is set to 0, and FCN is set the highest possible value correctly received.
depending on the number of fragment that will be sent in the window.
See Figure 23
The sender starts sending fragments indicating in the fragmentation <------ R ------>6 5 4 3 2 1 0 (*)
header with the current window and the FCN number. A delay between <- T -> 1
each fragment can be added to respect regulation rules or constraints | Rule ID | DTag |W|1|0|1|1|0|1|all-0|padding| Bitmap
imposed by the applications. This state can be leaved for different |--- byte boundary ----| 1 byte next |
reasons: (*)=(FCN values indicating the order)
o The FCN reaches value 0. In that case a all-0 fragmet is sent and +---- ... --+-... -+-+-+-+-+-+-+-+-+-+
the sender will wait for the bitmap acknowledged by the receiver. | Rule ID | DTag |W|1|0|1|1|0|1|1|P| transmitted Bitmap
+---- ... --+-... -+-+-+-+-+-+-+-+-+-+
|--- byte boundary ----| 1 byte next |
o The last fragment is sent. In that case a all-1 fragment is sent Figure 20: Example of the bitmap in Window mode, in any window except
and the sender will wait for the bitmap acknowledged by the the last one, for N=3)
receiver.
During the transition between the sending the fragment of the current Figure 21 shows an example of an ACK (N=3), where the bitmap
window and waiting for bitmap, the sender start listening to the indicates that the MIC check has failed but there is no missing
radio and start a timer. This timer is dimensioned to the receiving fragments.
window depending on the LPWAN technology.
In Ack on error mode, the timer expiration will be considered as a <------- R -------> 6 5 4 3 2 1 7 (*)
positive acknowledgment. If there are no more fragments then the <- T -> 1 1
fragmentation is finished. | Rule ID | DTag |W|0|1|1|1|1|1|1|1|padding| Bitmap
|---- byte boundary ----| 1 byte next | 1 byte next |
C
+---- ... --+-... -+-+-+-+
| Rule ID | DTag |W|0|1| transmitted Bitmap
+---- ... --+-... -+-+-+-+
|---- byte boundary -----|
(*) = (FCN values indicating the order)
If the sender receives a bitmap, it checks the window value. Figure 21: Example of the Bitmap in Window mode for the last window,
Acknowledgment with the non expected window are discarded. for N=3)
If the window number on the received bitmap is correct, the sender 5.6. Supporting multiple window sizes
compare the local bitmap with the received bitmap. If they are equal
all the fragments sent during the window have been well received. If
at least one fragment need to be sent, the sender clear the bitmap,
stop the timer and move its sending window to the next value. If no
more fragments have to be sent, then the fragmented packet
transmission is terminated.
If some fragments are missing (not set in the bit map) then the For ACK-Always or ACK-on-error, implementers may opt to support a
sender resend the missing fragments. When the retransmission is single window size or multiple window sizes. The latter, when
finished, it start listening to the bitmap (even if a All-0 or All-1 feasible, may provide performance optimizations. For example, a
has not been sent during the retransmission) and returns to the large window size may be used for packets that need to be carried by
waiting bitmap state. a large number of fragments. However, when the number of fragments
required to carry a packet is low, a smaller window size, and thus a
shorter bitmap, may be sufficient to provide feedback on all
fragments. If multiple window sizes are supported, the Rule ID may
be used to signal the window size in use for a specific packet
transmission.
If the local-bitmap is different from the received bitmap the counter Note that the same window size MUST be used for the transmission of
Attemps is increased and the sender resend the missing fragments all fragments that belong to a packet.
again, when a MAX_ATTEMPS is reached the sender sends an Abort and
goes to error.
+-------+ 5.7. Downlink fragment transmission
| |
| INIT |
| | FCN!=0 & more frags
+------++ +--+ ~~~~~~~~~~~~~~~~~~~~~~
W=0 | | | send Window + frag(FCN)
~~~~~~~~~~~~~~~~~~ | | | FCN-
Clear local bitmap | | v set local bitmap
FCN=max value | ++-------------+
+> | |
| SEND |
+--------------------------> | |
| ++-----+-------+
| FCN==0 & more frags| |last frag
| ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~~~~~~~~~~
| set local-bitmap| |set local-bitmap
| send wnd + frag(all-0)| |send wnd+frag(all-1)+MIC
| set Timer| |set Timer
| | |
|Timer expires & | | local-bitmap!=rcv-bitmap
|more fragments | | +-----------------+
|~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~~~~~ |
|stop Timer | | | Attemp++ |
|clear local.bitmap v v | v
|window = next window +-----+-----+--+--+ +----+----+
+---------------------->+ + | Resend |
| Wait bitmap | | Missing |
+-- + | | Frag |
not expected wnd | ++-+-------+---+--+ +------+--+
~~~~~~~~~~~~~~~~ | ^ | | ^ |
discard frag +----+ | | +-------------------+
| | all missing frag sent
| | ~~~~~~~~~~~~~~~~~~~~~
Timer expires & | | Set Timer
No more Frag | |
~~~~~~~~~~~~~~~~ | |
Stop Timer | | MAX_ATTEMPS > limit
+-----------+ | | ~~~~~~~~~~~~~~~~~~
| +<--------+ | Send Abort
| END | v
+-----------+ +-+----------+
| ERROR |
+------------+
Figure 23: Sender State Machine for the ACK on error Mode In some LPWAN technologies, as part of energy-saving techniques,
downlink transmission is only possible immediately after an uplink
transmission. In order to avoid potentially high delay for
fragmented datagram transmission in the downlink, the fragment
receiver MAY perform an uplink transmission as soon as possible after
reception of a fragment that is not the last one. Such uplink
transmission may be triggered by the L2 (e.g. an L2 ACK sent in
response to a fragment encapsulated in a L2 frame that requires an L2
ACK) or it may be triggered from an upper layer.
Unlike the sender, the receiver for ACK on error has some For fragmented packet transmission in the downlink, and when ACK
differences. First we are not sending the bitmap unless there is an Always is used, the fragment receiver MAY support timer-based ACK
error or an unexpected behavior. The Figure 24 finite state machine retransmission. In this mechanism, the fragment receiver initializes
describes the receiver behavior. The receiver starts with an the and starts a timer (the Inactivity Timer is used) after the
expecting window and maintain a local_bitmap indicating which transmission of an ACK, except when the ACK is sent in response to
fragments it has received (all-0 and all-1 occupy the same position). the last fragment of a packet (All-1 fragment). In the latter case,
the fragment receiver does not start a timer after transmission of
the ACK.
Any fragment not belonging to the current window is discarded. If, after transmission of an ACK that is not an All-1 fragment, and
Fragment belonging to the correct window are accepted, FN is computed before expiration of the corresponding Inactivity timer, the fragment
based on the FCN value. When an All-0 fragment is received and the receiver receives a fragment that belongs to the current window (e.g.
bitmap is full the receiver changes the window value and clear the a missing fragment from the current window) or to the next window,
bitmap. The receiver leaves this state when receiving a: the Inactivity timer for the ACK is stopped. However, if the
Inactivity timer expires, the ACK is resent and the Inactivity timer
is reinitialized and restarted.
o All-0 fragment and not a full bitmap indicate that all the The default initial value for the Inactivity timer, as well as the
fragments have been sent in the current window. Since the sender maximum number of retries for a specific ACK, denoted
is not obliged to send a full window, some fragment number not set MAX_ACK_RETRIES, are not defined in this document, and need to be
in the local_bitmap may not correspond to losses. As the receiver defined in other documents (e.g. technology-specific profiles). The
does not know if the missing fragments are looses or normal initial value of the Inactivity timer is expected to be greater than
missing fragments it sned s a local bitmap. that of the Retransmission timer, in order to make sure that a
(buffered) fragment to be retransmitted can find an opportunity for
that transmission.
o All-1 fragment which indicates that the transmission is finished. When the fragment sender transmits the All-1 fragment, it initializes
Since the last window is not full, the MIC will be used to detect and starts its retransmission timer to a long value (e.g. several
if all the fragments have been received. A correct MIC indicates times the initial Inactivity timer). If an ACK is received before
the end of the transmission. expiration of this timer, the fragment sender retransmits any lost
fragments reported by the ACK, or if the ACK confirms successful
reception of all fragments of the last window, transmission of the
fragmented packet ends. If the timer expires, and no ACK has been
received since the start of the timer, the fragment sender assumes
that the all-1 fragment has been successfully received (and possibly,
the last ACK has been lost: this mechanism assumes that the
retransmission timer for the all-1 fragment is long enough to allow
several ACK retries if the all-1 fragment has not been received by
the fragment receiver, and it also assumes that it is unlikely that
several ACKs become all lost).
If All-1 frag has not been received, the receiver expect a new 6. Padding management
window. It waits for the next fragment. If the window value has not
changed, the received fragments are part of a retransmission. A
receiver that has already received a frag should discard it (not
represented in the state machine), otherwise it completes its bitmap.
If all the bits of the bitmap are set to one, the receiver clear the
bitmap and wait for the next window without waiting for a all-0 frag.
While the receiver waits for next window and if the window value is
set to the next value, and all-1 fragment with the next value window
arrived the receiver goes to error and abort the transmission, it
drops the fragments.
If the receiver receives an all-0 fragment, it stays in the same SCHC header, either for compression, fragmentation or acknowledgment
state. Sender may send more one fragment per window or more. does not preserve byte alignment. Since most of the LPWAN network
Otherwise some fragments in the window have been lost. technologies payload is expressed in an integer number of bytes; the
sender will introduce at the end some padding bits while the receiver
must be able to eliminate them.
If the receiver receives an all-1 fragment this means that the The algorithm for padding bit elimination for compressed or
transmission should be finished. If the MIC is incorrect some fragmented frames is simple. Based on the following principle: * The
fragments have been lost. It sends its bitmap. SCHC header is not aligned on a byte boundary, but its size in bits
is given by the rule.
In case of an incorrect MIC, the receivers wait for fragment o The data size is variable, but always a multiple of 8 bits.
belonging to the same window.
Not All- & w=expected +---+ +---+w = Not expected o Padding bits MUST never exceed 7 bits.
~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~
Set local_bitmap(FCN) | v v |discard
++---+---+---+-+
+-----------------------+ +--+ All-0 & full
| | Rcv Window | | ~~~~~~~~~~~~
| +--------------------+ +<-+ w =next
| | +---+---+------+ clear lcl_bitmap
| | | ^
| | All-0 & w=expect| |w=expct & not-All & full
| | & no_full bitmap| |~~~~~~~~~~~~~~~~~~~~~~~~
| | ~~~~~~~~~~~~~~~~~| |clear lcl_bitmap; w =nxt
| | send local_bitmap| |
| | | | +--------+
| | | | +---------->+ |
| | | | |w=next | Error/ |
| | | | |~~~~~~~~ | Abort |
| | | | |Send abort ++-------+
| | v | | ^ w=expct
| | +-+---+--+------+ | & all-1
| | | Wait +------+ ~~~~~~~
| | | Next Window | Send abort
| | +-------+---+---+
| | All-1 & w=next & MIC wrong | |
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | +----------------+
| | set local_bitmap(FCN) | All-1 & w=next|
| | send local_bitmap | & MIC right|
| | | ~~~~~~~~~~~~~~~~~~|
| | | set lcl_bitmap(FCN)|
| |All-1 & w=expect & MIC wrong | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| |set local_bitmap(FCN) v |
| |send local_bitmap +-------+------+ |
| +--------------------->+ Wait End +-+ |
| +-----+------+-+ | w=expct & |
| w=expected & MIC right | ^ | MIC wrong |
| ~~~~~~~~~~~~~~~~~~~~~~ | +---+ ~~~~~~~~~ |
| set local_bitmap(FCN) | set lcl_bitmap(FCN)|
| | |
|All-1 & w=expected & MIC right | |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v |
|set local_bitmap(FCN) +-+----------+ |
+---------------------------->+ END +<----------+
+------------+
Figure 24: Receiver State Machine for the ACK on error Mode In that case, a receiver after decoding the SCHC header, must take
the maximum multiple of 8 bits as data. The remaining bits are
padding bits.
6. SCHC Compression for IPv6 and UDP headers 7. SCHC Compression for IPv6 and UDP headers
This section lists the different IPv6 and UDP header fields and how This section lists the different IPv6 and UDP header fields and how
they can be compressed. they can be compressed.
6.1. IPv6 version field 7.1. IPv6 version field
This field always holds the same value, therefore the TV is 6, the MO This field always holds the same value. Therefore, the TV is 6, the
is "equal" and the "CDA "not-sent"". MO is "equal" and the "CDA "not-sent"".
6.2. IPv6 Traffic class field 7.2. IPv6 Traffic class field
If the DiffServ field identified by the rest of the rule do not vary If the DiffServ field identified by the rest of the rule do not vary
and is known by both sides, the TV should contain this well-known and is known by both sides, the TV should contain this well-known
value, the MO should be "equal" and the CDA must be "not-sent. value, the MO should be "equal" and the CDA must be "not-sent.
If the DiffServ field identified by the rest of the rule varies over If the DiffServ field identified by the rest of the rule varies over
time or is not known by both sides, then there are two possibilities time or is not known by both sides, then there are two possibilities
depending on the variability of the value, the first one is to do not depending on the variability of the value, the first one is to do not
compressed the field and sends the original value, or the second compressed the field and sends the original value, or the second
where the values can be computed by sending only the LSB bits: where the values can be computed by sending only the LSB bits:
o TV is not set to any value, MO is set to "ignore" and CDA is set o TV is not set to any value, MO is set to "ignore" and CDA is set
to "value-sent" to "value-sent"
o TV contains a stable value, MO is MSB(X) and CDA is set to LSB o TV contains a stable value, MO is MSB(X) and CDA is set to LSB
6.3. Flow label field 7.3. Flow label field
If the Flow Label field identified by the rest of the rule does not If the Flow Label field identified by the rest of the rule does not
vary and is known by both sides, the TV should contain this well- vary and is known by both sides, the TV should contain this well-
known value, the MO should be "equal" and the CDA should be "not- known value, the MO should be "equal" and the CDA should be "not-
sent". sent".
If the Flow Label field identified by the rest of the rule varies If the Flow Label field identified by the rest of the rule varies
during time or is not known by both sides, there are two during time or is not known by both sides, there are two
possibilities depending on the variability of the value, the first possibilities depending on the variability of the value, the first
one is without compression and then the value is sent and the second one is without compression and then the value is sent and the second
where only part of the value is sent and the decompressor needs to where only part of the value is sent and the decompressor needs to
compute the original value: compute the original value:
o TV is not set, MO is set to "ignore" and CDA is set to "value- o TV is not set, MO is set to "ignore" and CDA is set to "value-
sent" sent"
o TV contains a stable value, MO is MSB(X) and CDA is set to LSB o TV contains a stable value, MO is MSB(X) and CDA is set to LSB
6.4. Payload Length field 7.4. Payload Length field
If the LPWAN technology does not add padding, this field can be If the LPWAN technology does not add padding, this field can be
elided for the transmission on the LPWAN network. The SCHC C/D elided for the transmission on the LPWAN network. The SCHC C/D
recomputes the original payload length value. The TV is not set, the recomputes the original payload length value. The TV is not set, the
MO is set to "ignore" and the CDA is "compute-IPv6-length". MO is set to "ignore" and the CDA is "compute-IPv6-length".
If the payload length needs to be sent and does not need to be coded If the payload length needs to be sent and does not need to be coded
in 16 bits, the TV can be set to 0x0000, the MO set to "MSB (16-s)" in 16 bits, the TV can be set to 0x0000, the MO set to "MSB (16-s)"
and the CDA to "LSB". The 's' parameter depends on the expected and the CDA to "LSB". The 's' parameter depends on the expected
maximum packet length. maximum packet length.
On other cases, the payload length field must be sent and the CDA is On other cases, the payload length field must be sent and the CDA is
replaced by "value-sent". replaced by "value-sent".
6.5. Next Header field 7.5. Next Header field
If the Next Header field identified by the rest of the rule does not If the Next Header field identified by the rest of the rule does not
vary and is known by both sides, the TV should contain this Next vary and is known by both sides, the TV should contain this Next
Header value, the MO should be "equal" and the CDA should be "not- Header value, the MO should be "equal" and the CDA should be "not-
sent". sent".
If the Next header field identified by the rest of the rule varies If the Next header field identified by the rest of the rule varies
during time or is not known by both sides, then TV is not set, MO is during time or is not known by both sides, then TV is not set, MO is
set to "ignore" and CDA is set to "value-sent". A matching-list may set to "ignore" and CDA is set to "value-sent". A matching-list may
also be used. also be used.
6.6. Hop Limit field 7.6. Hop Limit field
The End System is generally a device and does not forward packets, The End System is generally a device and does not forward packets.
therefore the Hop Limit value is constant. So the TV is set with a Therefore, the Hop Limit value is constant. So, the TV is set with a
default value, the MO is set to "equal" and the CDA is set to "not- default value, the MO is set to "equal" and the CDA is set to "not-
sent". sent".
Otherwise the value is sent on the LPWAN: TV is not set, MO is set to Otherwise the value is sent on the LPWAN: TV is not set, MO is set to
ignore and CDA is set to "value-sent". ignore and CDA is set to "value-sent".
Note that the field behavior differs in upstream and downstream. In Note that the field behavior differs in upstream and downstream. In
upstream, since there is no IP forwarding between the Dev and the upstream, since there is no IP forwarding between the Dev and the
SCHC C/D, the value is relatively constant. On the other hand, the SCHC C/D, the value is relatively constant. On the other hand, the
downstream value depends of Internet routing and may change more downstream value depends of Internet routing and may change more
frequently. One solution could be to use the Direction Indicator frequently. One solution could be to use the Direction Indicator
(DI) to distinguish both directions to elide the field in the (DI) to distinguish both directions to elide the field in the
upstream direction and send the value in the downstream direction. upstream direction and send the value in the downstream direction.
6.7. IPv6 addresses fields 7.7. IPv6 addresses fields
As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit
long fields; one for the prefix and one for the Interface Identifier long fields; one for the prefix and one for the Interface Identifier
(IID). These fields should be compressed. To allow a single rule, (IID). These fields should be compressed. To allow a single rule,
these values are identified by their role (DEV or APP) and not by these values are identified by their role (DEV or APP) and not by
their position in the frame (source or destination). The SCHC C/D their position in the frame (source or destination). The SCHC C/D
must be aware of the traffic direction (upstream, downstream) to must be aware of the traffic direction (upstream, downstream) to
select the appropriate field. select the appropriate field.
6.7.1. IPv6 source and destination prefixes 7.7.1. IPv6 source and destination prefixes
Both ends must be synchronized with the appropriate prefixes. For a Both ends must be synchronized with the appropriate prefixes. For a
specific flow, the source and destination prefix can be unique and specific flow, the source and destination prefix can be unique and
stored in the context. It can be either a link-local prefix or a stored in the context. It can be either a link-local prefix or a
global prefix. In that case, the TV for the source and destination global prefix. In that case, the TV for the source and destination
prefixes contains the values, the MO is set to "equal" and the CDA is prefixes contain the values, the MO is set to "equal" and the CDA is
set to "not-sent". set to "not-sent".
In case the rule allows several prefixes, mapping-list must be used. In case the rule allows several prefixes, mapping-list must be used.
The different prefixes are listed in the TV associated with a short The different prefixes are listed in the TV associated with a short
ID. The MO is set to "match-mapping" and the CDA is set to "mapping- ID. The MO is set to "match-mapping" and the CDA is set to "mapping-
sent". sent".
Otherwise the TV contains the prefix, the MO is set to "equal" and Otherwise the TV contains the prefix, the MO is set to "equal" and
the CDA is set to value-sent. the CDA is set to value-sent.
6.7.2. IPv6 source and destination IID 7.7.2. IPv6 source and destination IID
If the DEV or APP IID are based on an LPWAN address, then the IID can If the DEV or APP IID are based on an LPWAN address, then the IID can
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". Note that the LPWAN technology is is set to "DEViid" or "APPiid". Note that the LPWAN technology is
generally carrying a single device identifier corresponding to the generally carrying a single device identifier corresponding to the
DEV. The SCHC C/D may also not be aware of these values. DEV. The SCHC C/D may also not be aware of these values.
If the DEV address has a static value that is not derived from an If the DEV address has a static value that is not derived from an
IEEE EUI-64, then TV contains the actual Dev address value, the MO IEEE EUI-64, then TV contains the actual Dev address value, the MO
skipping to change at page 38, line 9 skipping to change at page 35, line 33
"mapping-sent". "mapping-sent".
Otherwise the value variation of the IID may be reduced to few bytes. Otherwise the value variation of the IID may be reduced to few bytes.
In that case, the TV is set to the stable part of the IID, the MO is 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. set to MSB and the CDA is set to LSB.
Finally, the IID can be sent on the LPWAN. In that case, the TV is Finally, the IID can be sent on the LPWAN. In that case, 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".
6.8. IPv6 extensions 7.8. IPv6 extensions
No extension rules are currently defined. They can be based on the No extension rules are currently defined. They can be based on the
MOs and CDAs described above. MOs and CDAs described above.
6.9. UDP source and destination port 7.9. UDP source and destination port
To allow a single rule, the UDP port values are identified by their To allow a single rule, the UDP port values are identified by their
role (DEV or APP) and not by their position in the frame (source or role (DEV or APP) and not by their position in the frame (source or
destination). The SCHC C/D must be aware of the traffic direction destination). The SCHC C/D must be aware of the traffic direction
(upstream, downstream) to select the appropriate field. The (upstream, downstream) to select the appropriate field. The
following rules apply for DEV and APP port numbers. following rules apply for DEV and APP 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-
sent". sent".
If the port variation is on few bits, the TV contains the stable part If the port variation is on few bits, the TV contains the stable part
of the port number, the MO is set to "MSB" and the CDA is set to of the port number, the MO is set to "MSB" and the CDA is set to
"LSB". "LSB".
If some well-known values are used, the TV can contain the list of If some well-known values are used, the TV can contain the list of
this values, the MO is set to "match-mapping" and the CDA is set to these values, the MO is set to "match-mapping" and the CDA is set to
"mapping-sent". "mapping-sent".
Otherwise the port numbers are sent on the LPWAN. The TV is not set, Otherwise the port numbers are sent on the LPWAN. The TV is not set,
the MO is set to "ignore" and the CDA is set to "value-sent". the MO is set to "ignore" and the CDA is set to "value-sent".
6.10. UDP length field 7.10. UDP length field
If the LPWAN technology does not introduce padding, the UDP length If the LPWAN technology does not introduce padding, the UDP length
can be computed from the received data. In that case the TV is not can be computed from the received data. In that case, the TV is not
set, the MO is set to "ignore" and the CDA is set to "compute-UDP- set, the MO is set to "ignore" and the CDA is set to "compute-UDP-
length". length".
If the payload is small, the TV can be set to 0x0000, the MO set to If the payload is small, the TV can be set to 0x0000, the MO set to
"MSB" and the CDA to "LSB". "MSB" and the CDA to "LSB".
On other cases, the length must be sent and the CDA is replaced by On other cases, the length must be sent and the CDA is replaced by
"value-sent". "value-sent".
6.11. UDP Checksum field 7.11. UDP Checksum field
IPv6 mandates a checksum in the protocol above IP. Nevertheless, if IPv6 mandates a checksum in the protocol above IP. Nevertheless, if
a more efficient mechanism such as L2 CRC or MIC is carried by or a more efficient mechanism such as L2 CRC or MIC is carried by or
over the L2 (such as in the LPWAN fragmentation process (see section over the L2 (such as in the LPWAN fragmentation process (see
Section 5)), the UDP checksum transmission can be avoided. In that Section 5)), the UDP checksum transmission can be avoided. 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 "compute-UDP-checksum". to "compute-UDP-checksum".
In other cases the checksum must be explicitly sent. The TV is not In other cases, the checksum must be explicitly sent. The TV is not
set, the MO is set to "ignore" and the CDF is set to "value-sent". set, the MO is set to "ignore" and the CDF is set to "value-sent".
7. Security considerations 8. Security considerations
7.1. Security considerations for header compression 8.1. Security considerations for header compression
A malicious header compression could cause the reconstruction of a A malicious header compression could cause the reconstruction of a
wrong packet that does not match with the original one, such wrong packet that does not match with the original one, such
corruption may be detected with end-to-end authentication and corruption may be detected with end-to-end authentication and
integrity mechanisms. Denial of Service may be produced but its integrity mechanisms. Denial of Service may be produced but its
arise other security problems that may be solved with or without arise other security problems that may be solved with or without
header compression. header compression.
7.2. Security considerations for fragmentation 8.2. Security considerations for fragmentation
This subsection describes potential attacks to LPWAN fragmentation This subsection describes potential attacks to LPWAN fragmentation
and suggests possible countermeasures. and suggests possible countermeasures.
A node can perform a buffer reservation attack by sending a first A node can perform a buffer reservation attack by sending a first
fragment to a target. Then, the receiver will reserve buffer space fragment to a target. Then, the receiver will reserve buffer space
for the IPv6 packet. Other incoming fragmented packets will be for the IPv6 packet. Other incoming fragmented 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. procedure, and iterate, thus creating a denial of service attack.
skipping to change at page 40, line 31 skipping to change at page 38, line 5
increase consumption of the fragment sender's resources. To this increase consumption of the fragment sender's resources. To this
end, the malicious node may repeatedly send a fake ACK to the end, the malicious node may repeatedly send a fake ACK to the
fragment sender, with a bitmap that reports that one or more fragment sender, with a bitmap that reports that one or more
fragments have been lost. In order to mitigate this possible attack, fragments have been lost. In order to mitigate this possible attack,
MAX_FRAG_RETRIES may be set to a safe value which allows to limit the MAX_FRAG_RETRIES may be set to a safe value which allows to limit the
maximum damage of the attack to an acceptable extent. However, note maximum damage of the attack to an acceptable extent. However, note
that a high setting for MAX_FRAG_RETRIES benefits fragment delivery that a high setting for MAX_FRAG_RETRIES benefits fragment delivery
reliability, therefore the trade-off needs to be carefully reliability, therefore the trade-off needs to be carefully
considered. considered.
8. Acknowledgements 9. Acknowledgements
Thanks to Dominique Barthel, Carsten Bormann, Philippe Clavier, Thanks to Dominique Barthel, Carsten Bormann, Philippe Clavier,
Arunprabhu Kandasamy, Antony Markovski, Alexander Pelov, Pascal Arunprabhu Kandasamy, Antony Markovski, Alexander Pelov, Pascal
Thubert, Juan Carlos Zuniga and Diego Dujovne for useful design Thubert, Juan Carlos Zuniga and Diego Dujovne for useful design
consideration and comments. consideration and comments.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[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>.
[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>.
9.2. Informative References 10.2. Informative References
[I-D.ietf-lpwan-overview] [I-D.ietf-lpwan-overview]
Farrell, S., "LPWAN Overview", draft-ietf-lpwan- Farrell, S., "LPWAN Overview", draft-ietf-lpwan-
overview-07 (work in progress), October 2017. overview-07 (work in progress), October 2017.
Appendix A. SCHC Compression Examples Appendix A. SCHC 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 SCHC behavior. IPv6/UDP. The goal is to illustrate the SCHC behavior.
The most common case using the mechanisms defined in this document The most common case using the mechanisms defined in this document
will be a LPWAN Dev that embeds some applications running over CoAP. will be a LPWAN Dev that embeds some applications running over CoAP.
In this example, three flows are considered. The first flow is for In this example, three flows are considered. The first flow is for
the device management based on CoAP using Link Local IPv6 addresses the device management based on CoAP using Link Local IPv6 addresses
and UDP ports 123 and 124 for Dev and App, respectively. The second and UDP ports 123 and 124 for Dev and App, respectively. The second
flow will be a CoAP server for measurements done by the Device (using flow will be a CoAP server for measurements done by the Device (using
ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to
beta::1/64. The last flow is for legacy applications using different beta::1/64. The last flow is for legacy applications using different
ports numbers, the destination IPv6 address prefix is gamma::1/64. ports numbers, the destination IPv6 address prefix is gamma::1/64.
Figure 25 presents the protocol stack for this Device. IPv6 and UDP Figure 22 presents the protocol stack for this Device. IPv6 and UDP
are represented with dotted lines since these protocols are are represented with dotted lines since these protocols are
compressed on the radio link. compressed on the radio link.
Management Data Management Data
+----------+---------+---------+ +----------+---------+---------+
| CoAP | CoAP | legacy | | CoAP | CoAP | legacy |
+----||----+---||----+---||----+ +----||----+---||----+---||----+
. UDP . UDP | UDP | . UDP . UDP | UDP |
................................ ................................
. IPv6 . IPv6 . IPv6 . . IPv6 . IPv6 . IPv6 .
+------------------------------+ +------------------------------+
| SCHC Header compression | | SCHC Header compression |
| and fragmentation | | and fragmentation |
+------------------------------+ +------------------------------+
| LPWAN L2 technologies | | LPWAN L2 technologies |
+------------------------------+ +------------------------------+
DEV or NGW DEV or NGW
Figure 25: Simplified Protocol Stack for LP-WAN Figure 22: Simplified Protocol Stack for LP-WAN
Note that in some LPWAN technologies, only the Devs have a device ID. Note that in some LPWAN technologies, only the Devs have a device ID.
Therefore, when such technologies are used, it is necessary to define Therefore, when such technologies are used, it is necessary to define
statically an IID for the Link Local address for the SCHC C/D. statically an IID for the Link Local address for the SCHC C/D.
Rule 0 Rule 0
+----------------+--+--+--+---------+--------+------------++------+ +----------------+--+--+--+---------+--------+------------++------+
| Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent |
| | | | | | Opera. | Action ||[bits]| | | | | | | Opera. | Action ||[bits]|
+----------------+--+--+--+---------+---------------------++------+ +----------------+--+--+--+---------+---------------------++------+
skipping to change at page 43, line 47 skipping to change at page 41, line 7
|IPv6 DEViid |64|1 |Bi| | ignore | DEViid || | |IPv6 DEViid |64|1 |Bi| | ignore | DEViid || |
|IPv6 APPprefix |64|1 |Bi|gamma/64 | equal | not-sent || | |IPv6 APPprefix |64|1 |Bi|gamma/64 | equal | not-sent || |
|IPv6 APPiid |64|1 |Bi|::1000 | equal | not-sent || | |IPv6 APPiid |64|1 |Bi|::1000 | equal | not-sent || |
+================+==+==+==+=========+========+============++======+ +================+==+==+==+=========+========+============++======+
|UDP DEVport |16|1 |Bi|8720 | MSB(12)| LSB(4) || [4] | |UDP DEVport |16|1 |Bi|8720 | MSB(12)| LSB(4) || [4] |
|UDP APPport |16|1 |Bi|8720 | MSB(12)| LSB(4) || [4] | |UDP APPport |16|1 |Bi|8720 | MSB(12)| LSB(4) || [4] |
|UDP Length |16|1 |Bi| | ignore | comp-length|| | |UDP Length |16|1 |Bi| | ignore | comp-length|| |
|UDP checksum |16|1 |Bi| | ignore | comp-chk || | |UDP checksum |16|1 |Bi| | ignore | comp-chk || |
+================+==+==+==+=========+========+============++======+ +================+==+==+==+=========+========+============++======+
Figure 26: Context rules Figure 23: Context rules
All the fields described in the three rules depicted on Figure 26 are All the fields described in the three rules depicted on Figure 23 are
present in the IPv6 and UDP headers. The DEViid-DID value is found present in the IPv6 and UDP headers. The DEViid-DID value is found
in the L2 header. in the L2 header.
The second and third rules use global addresses. The way the Dev The second and third rules use global addresses. The way the Dev
learns the prefix is not in the scope of the document. learns the prefix is not in the scope of the document.
The third rule compresses port numbers to 4 bits. The third rule compresses port numbers to 4 bits.
Appendix B. Fragmentation Examples Appendix B. Fragmentation Examples
This section provides examples of different fragment delivery This section provides examples of different fragment delivery
reliability options possible on the basis of this specification. reliability options possible on the basis of this specification.
Figure 27 illustrates the transmission of an IPv6 packet that needs Figure 24 illustrates the transmission of an IPv6 packet that needs
11 fragments in the No ACK option, FCN is always 1 bit. 11 fragments in the No ACK option, FCN is always 1 bit.
Sender Receiver Sender Receiver
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=1-------->|MIC checked => |-------FCN=1-------->|MIC checked =>
Figure 27: Transmission of an IPv6 packet carried by 11 fragments in Figure 24: Transmission of an IPv6 packet carried by 11 fragments in
the No ACK option the No ACK option
Figure 28 illustrates the transmission of an IPv6 packet that needs Figure 25 illustrates the transmission of an IPv6 packet that needs
11 fragments in Window mode - ACK on error, for N=3, without losses. 11 fragments in ACK-on-error, for N=3, without losses.
Sender Receiver Sender Receiver
|-----W=1, FCN=6----->|
|-----W=1, FCN=5----->|
|-----W=1, FCN=4----->|
|-----W=1, FCN=3----->|
|-----W=1, FCN=2----->|
|-----W=1, FCN=1----->|
|-----W=1, FCN=0----->|
(no ACK)
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4----->| |-----W=0, FCN=4----->|
|-----W=0, FCN=7----->|MIC checked => |-----W=0, FCN=3----->|
|-----W=0, FCN=2----->|
|-----W=0, FCN=1----->|
|-----W=0, FCN=0----->|
(no ACK) (no ACK)
|-----W=1, FCN=6----->|
|-----W=1, FCN=5----->|
|-----W=1, FCN=4----->|
|-----W=1, FCN=7----->|MIC checked =>
|<---- ACK, W=1 ------|
Figure 28: Transmission of an IPv6 packet carried by 11 fragments in Figure 25: Transmission of an IPv6 packet carried by 11 fragments in
Window mode - ACK on error, for N=3 and MAX_WIND_FCN=6, without ACK-on-error, for N=3 and MAX_WIND_FCN=6, without losses.
losses.
Figure 29 illustrates the transmission of an IPv6 packet that needs Figure 26 illustrates the transmission of an IPv6 packet that needs
11 fragments in Window mode - ACK on error, for N=3, with three 11 fragments ACK-on-error, for N=3, with three losses.
losses.
Sender Receiver Sender Receiver
|-----W=1, FCN=6----->|
|-----W=1, FCN=5----->|
|-----W=1, FCN=4--X-->|
|-----W=1, FCN=3----->|
|-----W=1, FCN=2--X-->|
|-----W=1, FCN=1----->|
|-----W=1, FCN=0----->|
|<-----ACK, W=1-------|Bitmap:11010111
|-----W=1, FCN=4----->|
|-----W=1, FCN=2----->|
(no ACK)
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->| |-----W=0, FCN=4--X-->|
|-----W=0, FCN=7----->|MIC checked |-----W=0, FCN=3----->|
|<-----ACK, W=0-------|Bitmap:11000001 |-----W=0, FCN=2--X-->|
|-----W=0, FCN=4----->|MIC checked => |-----W=0, FCN=1----->|
|-----W=0, FCN=0----->|
|<-----ACK, W=0-------|Bitmap:11010111
|-----W=0, FCN=4----->|
|-----W=0, FCN=2----->|
(no ACK) (no ACK)
|-----W=1, FCN=6----->|
|-----W=1, FCN=5----->|
|-----W=1, FCN=4--X-->|
|-----W=1, FCN=7----->|MIC checked
|<-----ACK, W=1-------|Bitmap:11000001
|-----W=1, FCN=4----->|MIC checked =>
|<---- ACK, W=1 ------|
Figure 29: Transmission of an IPv6 packet carried by 11 fragments in Figure 26: Transmission of an IPv6 packet carried by 11 fragments in
Window mode - ACK on error, for N=3 and MAX_WIND_FCN=6, three losses. ACK-on-error, for N=3 and MAX_WIND_FCN=6, three losses.
Figure 30 illustrates the transmission of an IPv6 packet that needs Figure 27 illustrates the transmission of an IPv6 packet that needs
11 fragments in Window mode - ACK "always", for N=3 and 11 fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, without
MAX_WIND_FCN=6, without losses. Note: in Window mode, an additional losses. Note: in Window mode, an additional bit will be needed to
bit will be needed to number windows. number windows.
Sender Receiver Sender Receiver
|-----W=1, FCN=6----->|
|-----W=1, FCN=5----->|
|-----W=1, FCN=4----->|
|-----W=1, FCN=3----->|
|-----W=1, FCN=2----->|
|-----W=1, FCN=1----->|
|-----W=1, FCN=0----->|
|<-----ACK, W=1-------|no bitmap
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4----->| |-----W=0, FCN=4----->|
|-----W=0, FCN=7----->|MIC checked => |-----W=0, FCN=3----->|
|<-----ACK, W=0-------|no bitmap |-----W=0, FCN=2----->|
|-----W=0, FCN=1----->|
|-----W=0, FCN=0----->|
|<-----ACK, W=0-------|no Bitmap
|-----W=1, FCN=6----->|
|-----W=1, FCN=5----->|
|-----W=1, FCN=4----->|
|-----W=1, FCN=7----->|MIC checked =>
|<-----ACK, W=1-------|no Bitmap
(End) (End)
Figure 30: Transmission of an IPv6 packet carried by 11 fragments in Figure 27: Transmission of an IPv6 packet carried by 11 fragments in
Window mode - ACK "always", for N=3 and MAX_WIND_FCN=6, no losses. ACK-Always, for N=3 and MAX_WIND_FCN=6, no losses.
Figure 31 illustrates the transmission of an IPv6 packet that needs Figure 28 illustrates the transmission of an IPv6 packet that needs
11 fragments in Window mode - ACK "always", for N=3 and 11 fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, with three
MAX_WIND_FCN=6, with three losses. losses.
Sender Receiver Sender Receiver
|-----W=1, FCN=6----->| |-----W=1, FCN=6----->|
|-----W=1, FCN=5----->| |-----W=1, FCN=5----->|
|-----W=1, FCN=4--X-->| |-----W=1, FCN=4--X-->|
|-----W=1, FCN=3----->| |-----W=1, FCN=3----->|
|-----W=1, FCN=2--X-->| |-----W=1, FCN=2--X-->|
|-----W=1, FCN=1----->| |-----W=1, FCN=1----->|
|-----W=1, FCN=0----->| |-----W=1, FCN=0----->|
|<-----ACK, W=1-------|bitmap:11010111 |<-----ACK, W=1-------|Bitmap:11010111
|-----W=1, FCN=4----->| |-----W=1, FCN=4----->|
|-----W=1, FCN=2----->| |-----W=1, FCN=2----->|
|<-----ACK, W=1-------|no bitmap |<-----ACK, W=1-------|no Bitmap
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->| |-----W=0, FCN=4--X-->|
|-----W=0, FCN=7----->|MIC checked |-----W=0, FCN=7----->|MIC checked
|<-----ACK, W=0-------|bitmap:11000001 |<-----ACK, W=0-------|Bitmap:11000001
|-----W=0, FCN=4----->|MIC checked => |-----W=0, FCN=4----->|MIC checked =>
|<-----ACK, W=0-------|no bitmap |<-----ACK, W=0-------|no Bitmap
(End) (End)
Figure 31: Transmission of an IPv6 packet carried by 11 fragments in Figure 28: Transmission of an IPv6 packet carried by 11 fragments in
Window mode - ACK "Always", for N=3, and MAX_WIND_FCN=6, with three ACK-Always, for N=3, and MAX_WIND_FCN=6, with three losses.
losses.
Figure 32 illustrates the transmission of an IPv6 packet that needs 6 Figure 29 illustrates the transmission of an IPv6 packet that needs 6
fragments in Window mode - ACK "always", for N=3 and MAX_WIND_FCN=6, fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, with three
with three losses, and only one retry is needed for each lost losses, and only one retry is needed for each lost fragment. Note
fragment. Note that, since a single window is needed for that, since a single window is needed for transmission of the IPv6
transmission of the IPv6 packet in this case, the example illustrates packet in this case, the example illustrates behavior when losses
behavior when losses happen in the last window. happen in the last window.
Sender Receiver Sender Receiver
|-----W=0, CFN=6----->| |-----W=0, CFN=6----->|
|-----W=0, CFN=5----->| |-----W=0, CFN=5----->|
|-----W=0, CFN=4--X-->| |-----W=0, CFN=4--X-->|
|-----W=0, CFN=3--X-->| |-----W=0, CFN=3--X-->|
|-----W=0, CFN=2--X-->| |-----W=0, CFN=2--X-->|
|-----W=0, CFN=7----->|MIC checked |-----W=0, CFN=7----->|MIC checked
|<-----ACK, W=0-------|bitmap:11000001 |<-----ACK, W=0-------|Bitmap:11000001
|-----W=0, CFN=4----->|MIC checked: failed |-----W=0, CFN=4----->|MIC checked: failed
|-----W=0, CFN=3----->|MIC checked: failed |-----W=0, CFN=3----->|MIC checked: failed
|-----W=0, CFN=2----->|MIC checked: success |-----W=0, CFN=2----->|MIC checked: success
|<-----ACK, W=0-------|no bitmap |<-----ACK, W=0-------|no Bitmap
(End) (End)
Figure 32: Transmission of an IPv6 packet carried by 11 fragments in Figure 29: Transmission of an IPv6 packet carried by 11 fragments in
Window mode - ACK "Always", for N=3, and MAX_WIND_FCN=6, with three ACK-Always, for N=3, and MAX_WIND_FCN=6, with three losses, and only
losses, and only one retry is needed for each lost fragment. one retry is needed for each lost fragment.
Figure 33 illustrates the transmission of an IPv6 packet that needs 6 Figure 30 illustrates the transmission of an IPv6 packet that needs 6
fragments in Window mode - ACK "always", for N=3 and MAX_WIND_FCN=6, fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, with three
with three losses, and the second ACK is lost. Note that, since a losses, and the second ACK is lost. Note that, since a single window
single window is needed for transmission of the IPv6 packet in this is needed for transmission of the IPv6 packet in this case, the
case, the example illustrates behavior when losses happen in the last example illustrates behavior when losses happen in the last window.
window.
Sender Receiver Sender Receiver
|-----W=0, CFN=6----->| |-----W=0, CFN=6----->|
|-----W=0, CFN=5----->| |-----W=0, CFN=5----->|
|-----W=0, CFN=4--X-->| |-----W=0, CFN=4--X-->|
|-----W=0, CFN=3--X-->| |-----W=0, CFN=3--X-->|
|-----W=0, CFN=2--X-->| |-----W=0, CFN=2--X-->|
|-----W=0, CFN=7----->|MIC checked |-----W=0, CFN=7----->|MIC checked
|<-----ACK, W=0-------|bitmap:11000001 |<-----ACK, W=0-------|Bitmap:11000001
|-----W=0, CFN=4----->|MIC checked: wrong |-----W=0, CFN=4----->|MIC checked: wrong
|-----W=0, CFN=3----->|MIC checked: wrong |-----W=0, CFN=3----->|MIC checked: wrong
|-----W=0, CFN=2----->|MIC checked: right |-----W=0, CFN=2----->|MIC checked: right
| X---ACK, W=0-------|no bitmap | X---ACK, W=0-------|no Bitmap
timeout | | timeout | |
|-----W=0, CFN=7----->| |-----W=0, CFN=7----->|
|<-----ACK, W=0-------|no bitmap |<-----ACK, W=0-------|no Bitmap
(End) (End)
Figure 33: Transmission of an IPv6 packet carried by 11 fragments in Figure 30: Transmission of an IPv6 packet carried by 11 fragments in
Window mode - ACK "Always", for N=3, and MAX_WIND_FCN=6, with three ACK-Always, for N=3, and MAX_WIND_FCN=6, with three losses, and the
losses, and the second ACK is lost. second ACK is lost.
Figure 34 illustrates the transmission of an IPv6 packet that needs 6 Figure 31 illustrates the transmission of an IPv6 packet that needs 6
fragments in Window mode - ACK "always", for N=3 and MAX_WIND_FCN=6, fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, with three
with three losses, and one retransmitted fragment is lost. Note losses, and one retransmitted fragment is lost. Note that, since a
that, since a single window is needed for transmission of the IPv6 single window is needed for transmission of the IPv6 packet in this
packet in this case, the example illustrates behavior when losses case, the example illustrates behavior when losses happen in the last
happen in the last window. window.
Sender Receiver Sender Receiver
|-----W=0, CFN=6----->| |-----W=0, CFN=6----->|
|-----W=0, CFN=5----->| |-----W=0, CFN=5----->|
|-----W=0, CFN=4--X-->| |-----W=0, CFN=4--X-->|
|-----W=0, CFN=3--X-->| |-----W=0, CFN=3--X-->|
|-----W=0, CFN=2--X-->| |-----W=0, CFN=2--X-->|
|-----W=0, CFN=7----->|MIC checked |-----W=0, CFN=7----->|MIC checked
|<-----ACK, W=0-------|bitmap:11000001 |<-----ACK, W=0-------|Bitmap:11000001
|-----W=0, CFN=4----->|MIC checked: wrong |-----W=0, CFN=4----->|MIC checked: wrong
|-----W=0, CFN=3----->|MIC checked: wrong |-----W=0, CFN=3----->|MIC checked: wrong
|-----W=0, CFN=2--X-->| |-----W=0, CFN=2--X-->|
timeout| | timeout| |
|-----W=0, CFN=7----->| |-----W=0, CFN=7----->|All-0 empty
|<-----ACK, W=0-------|bitmap:11110001 |<-----ACK, W=0-------|Bitmap:11110001
|-----W=0, CFN=2----->|MIC checked: right |-----W=0, CFN=2----->|MIC checked: right
|<-----ACK, W=0-------|no bitmap |<-----ACK, W=0-------|no Bitmap
(End) (End)
Figure 34: Transmission of an IPv6 packet carried by 11 fragments in Figure 31: Transmission of an IPv6 packet carried by 11 fragments in
Window mode - ACK "Always", for N=3, and MAX_WIND_FCN=6, with three ACK-Always, for N=3, and MAX_WIND_FCN=6, with three losses, and one
losses, and one retransmitted fragment is lost. retransmitted fragment is lost.
Appendix C illustrates the transmission of an IPv6 packet that needs Appendix C illustrates the transmission of an IPv6 packet that needs
28 fragments in Window mode - ACK "always", for N=5 and 28 fragments in ACK-Always, for N=5 and MAX_WIND_FCN=23, with two
MAX_WIND_FCN=23, with two losses. Note that MAX_WIND_FCN=23 may be losses. Note that MAX_WIND_FCN=23 may be useful when the maximum
useful when the maximum possible bitmap size, considering the maximum possible bitmap size, considering the maximum lower layer technology
lower layer technology payload size and the value of R, is 3 bytes. payload size and the value of R, is 3 bytes. Note also that the FCN
Note also that the FCN of the last fragment of the packet is the one of the last fragment of the packet is the one with FCN=31 (i.e.
with FCN=31 (i.e. FCN=2^N-1 for N=5, or equivalently, all FCN bits FCN=2^N-1 for N=5, or equivalently, all FCN bits set to 1).
set to 1).
Sender Receiver Sender Receiver
|-----W=1, CFN=23----->| |-----W=0, CFN=23----->|
|-----W=1, CFN=22----->| |-----W=0, CFN=22----->|
|-----W=1, CFN=21--X-->| |-----W=0, CFN=21--X-->|
|-----W=1, CFN=20----->| |-----W=0, CFN=20----->|
|-----W=1, CFN=19----->| |-----W=0, CFN=19----->|
|-----W=1, CFN=18----->| |-----W=0, CFN=18----->|
|-----W=1, CFN=17----->| |-----W=0, CFN=17----->|
|-----W=1, CFN=16----->| |-----W=0, CFN=16----->|
|-----W=1, CFN=15----->| |-----W=0, CFN=15----->|
|-----W=1, CFN=14----->| |-----W=0, CFN=14----->|
|-----W=1, CFN=13----->| |-----W=0, CFN=13----->|
|-----W=1, CFN=12----->| |-----W=0, CFN=12----->|
|-----W=1, CFN=11----->| |-----W=0, CFN=11----->|
|-----W=1, CFN=10--X-->| |-----W=0, CFN=10--X-->|
|-----W=1, CFN=9 ----->| |-----W=0, CFN=9 ----->|
|-----W=1, CFN=8 ----->| |-----W=0, CFN=8 ----->|
|-----W=1, CFN=7 ----->| |-----W=0, CFN=7 ----->|
|-----W=1, CFN=6 ----->| |-----W=0, CFN=6 ----->|
|-----W=1, CFN=5 ----->| |-----W=0, CFN=5 ----->|
|-----W=1, CFN=4 ----->| |-----W=0, CFN=4 ----->|
|-----W=1, CFN=3 ----->| |-----W=0, CFN=3 ----->|
|-----W=1, CFN=2 ----->| |-----W=0, CFN=2 ----->|
|-----W=1, CFN=1 ----->| |-----W=0, CFN=1 ----->|
|-----W=1, CFN=0 ----->| |-----W=0, CFN=0 ----->|
|<------ACK, W=1-------|bitmap:110111111111101111111111 | |lcl-Bitmap:110111111111101111111111
|-----W=1, CFN=21----->| |<------ACK, W=0-------| Bitmap:1101111111111011
|-----W=1, CFN=10----->| |-----W=0, CFN=21----->|
|<------ACK, W=1-------|no bitmap |-----W=0, CFN=10----->|
|-----W=0, CFN=23----->| |<------ACK, W=0-------|no Bitmap
|-----W=0, CFN=22----->| |-----W=1, CFN=23----->|
|-----W=0, CFN=21----->| |-----W=1, CFN=22----->|
|-----W=0, CFN=31----->|MIC checked => |-----W=1, CFN=21----->|
|<------ACK, W=0-------|no bitmap |-----W=1, CFN=31----->|MIC checked =>
(End) |<------ACK, W=1-------|no Bitmap
(End)
Appendix C. Allocation of Rule IDs for fragmentation Appendix C. Fragmentation State Machines
The fragmentation state machines of the sender and the receiver in
the different reliability options are next in the following figures:
+-----------+
+------------+ Init |
| FCN=0 +-----------+
| No Window
| No Bitmap
| +-------+
| +--------+--+ | More Fragments
| | | <--+ ~~~~~~~~~~~~~~~~~~~~
+--------> | Send | send Fragment (FCN=0)
+---+-------+
| last fragment
| ~~~~~~~~~~~~
| FCN = 1
v send fragment+MIC
+------------+
| END |
+------------+
Figure 32: Sender State Machine for the No ACK Mode
+------+ Not All-1
+----------+-+ | ~~~~~~~~~~~~~~~~~~~
| + <--+ set Inactivity Timer
| RCV Frag +-------+
+-+---+------+ |All-1 &
All-1 & | | |MIC correct
MIC wrong | |Inactivity |
| |Timer Exp. |
v | |
+----------++ | v
| Error |<-+ +--------+--+
+-----------+ | END |
+-----------+
Figure 33: Receiver State Machine for the No ACK Mode
+-------+
| INIT | FCN!=0 & more frags
| | ~~~~~~~~~~~~~~~~~~~~~~
+------++ +--+ send Window + frag(FCN)
W=0 | | | FCN-
Clear local bitmap | | v set local bitmap
FCN=max value | ++--+--------+
+> | |
+---------------------> | SEND |
| +--+-----+---+
| FCN==0 & more frags | | last frag
| ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~
| set local-bitmap | | set local-bitmap
| send wnd + frag(all-0) | | send wnd+frag(all-1)+MIC
| set Retrans_Timer | | set Retrans_Timer
| | |
|Recv_wnd == wnd & | |
|Lcl_bitmap==recv_bitmap& | | +------------------------+
|more frag | | |local-bitmap!=rcv-bitmap|
|~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ |
|Stop Retrans_Timer | | | Attemp++ v
|clear local_bitmap v v | +------++
|window=next_window +----+-----+--+--+ |Resend |
+---------------------+ | |Missing|
+----+ Wait | |Frag |
not expected wnd | | bitmap | +------++
~~~~~~~~~~~~~~~~ +--->+ +-+Retrans_Timer Exp |
discard frag +--+-+---+-+---+-+ |~~~~~~~~~~~~~~~~~ |
| | | ^ ^ |reSend(empty)All-* |
| | | | | |Set Retrans_Timer |
MIC_bit==1 & | | | | +---+Attemp++ |
Recv_window==window & | | | +---------------------------+
Lcl_bitmap==recv_bitmap &| | | all missing frag sent
no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer
Stop Retrans_Timer| | |
+-------------+ | | |
| END +<--------+ | | Attemp > MAX_ACK_REQUESTS
+-------------+ | | ~~~~~~~~~~~~~~~~~~
All-1 Window | v Send Abort
~~~~~~~~~~~~ | +-+-----------+
MIC_bit ==0 & +>| ERROR |
Lcl_bitmap==recv_bitmap +-------------+
Figure 34: Sender State Machine for the ACK Always Mode
Not All- & w=expected +---+ +---+w = Not expected
~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~
Set local_bitmap(FCN) | v v |discard
++---+---+---+-+
+---------------------+ Rcv +--->* ABORT
| +------------------+ Window |
| | +-----+--+-----+
| | All-0 & w=expect | ^ w =next & not-All
| | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~
| | set lcl_bitmap(FCN)| |expected = next window
| | send local_bitmap | |Clear local_bitmap
| | | |
| | w=expct & not-All | |
| | ~~~~~~~~~~~~~~~~~~ | |
| | set lcl_bitmap(FCN)+-+ | | +--+ w=next & All-0
| | if lcl_bitmap full | | | | | | ~~~~~~~~~~~~~~~
| | send lcl_bitmap v | v | | | expct = nxt wnd
| | +-+-+-+--+-++ | Clear lcl_bitmap
| | w=expected & +->+ Wait +<+ set lcl_bitmap(FCN)
| | All-1 | | Next | send lcl_bitmap
| | ~~~~~~~~~~~~ +--+ Window +--->* ABORT
| | discard +--------+-++
| | All-1 & w=next| | All-1 & w=nxt
| | & MIC wrong| | & MIC right
| | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~
| | set local_bitmap(FCN)| |set lcl_bitmap(FCN)
| | send local_bitmap| |send local_bitmap
| | | +----------------------+
| |All-1 & w=expct | |
| |& MIC wrong v +---+ w=expctd & |
| |~~~~~~~~~~~~~~~~~~~~ +----+---+-+ | MIC wrong |
| |set local_bitmap(FCN) | +<+ ~~~~~~~~~~~~~~ |
| |send local_bitmap | Wait End | set lcl_btmp(FCN)|
| +--------------------->+ +--->* ABORT |
| +---+----+-+ |
| w=expected & MIC right| |
| ~~~~~~~~~~~~~~~~~~~~~~| +-+ Not All-1 |
| set local_bitmap(FCN)| | | ~~~~~~~~~ |
| send local_bitmap| | | discard |
| | | | |
|All-1 & w=expctd & MIC right | | | +-+ All-1 |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v | v ~~~~~~~~~ |
|set local_bitmap(FCN) +-+-+-+-+-++Send lcl_btmp |
|send local_bitmap | | |
+-------------------------->+ END +<---------------+
++--+------+
--->* ABORT
~~~~~~~
Inactivity_Timer = expires
When DWN_Link
IF Inactivity_Timer expires
Send DWL Request
Attemp++
Figure 35: Receiver State Machine for the ACK Always Mode
+-------+
| |
| INIT |
| | FCN!=0 & more frags
+------++ +--+ ~~~~~~~~~~~~~~~~~~~~~~
W=0 | | | send Window + frag(FCN)
~~~~~~~~~~~~~~~~~~ | | | FCN-
Clear local bitmap | | v set local bitmap
FCN=max value | ++-------------+
+> | |
| SEND |
+-------------------------> | |
| ++-----+-------+
| FCN==0 & more frags| |last frag
| ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~~~~~~~~~~
| set local-bitmap| |set local-bitmap
| send wnd + frag(all-0)| |send wnd+frag(all-1)+MIC
| set Retrans_Timer| |set Retrans_Timer
| | |
|Retrans_Timer expires & | | local-bitmap!=rcv-bitmap
|more fragments | | +-----------------+
|~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~~~~~ |
|stop Retrans_Timer | | | Attemp++ |
|clear local.bitmap v v | v
|window = next window +-----+-----+--+--+ +----+----+
+----------------------+ + | Resend |
+--------------------->+ Wait bitmap | | Missing |
| +-- + | | Frag |
| not expected wnd | ++-+---+---+---+--+ +------+--+
| ~~~~~~~~~~~~~~~~ | ^ | | | ^ |
| discard frag +----+ | | | +-------------------+
| | | | all missing frag sent
|Retrans_Timer expires & | | | ~~~~~~~~~~~~~~~~~~~~~
| No more Frag | | | Set Retrans_Timer
| ~~~~~~~~~~~~~~~~~~~~~~~ | | |
| Stop Retrans_Timer | | |
| Send ALL-1-empty | | |
+-------------------------+ | |
| |
Local_bitmap==Recv_bitmap| |
~~~~~~~~~~~~~~~~~~~~~~~~~| |Attemp > MAX_ACK_REQUESTS
+---------+Stop Retrans_Timer | |~~~~~~~~~~~~~~~~~~~~~~~
| END +<------------------+ v Send Abort
+---------+ +-+---------+
| ERROR |
+-----------+
Figure 36: Sender State Machine for the ACK on error Mode
Not All- & w=expected +---+ +---+w = Not expected
~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~
Set local_bitmap(FCN) | v v |discard
++---+---+---+-+
+-----------------------+ +--+ All-0 & full
| ABORT *<---+ Rcv Window | | ~~~~~~~~~~~~
| +--------------------+ +<-+ w =next
| | +---+---+------+ clear lcl_bitmap
| | | ^
| | All-0 & w=expect| |w=expct & not-All & full
| | & no_full bitmap| |~~~~~~~~~~~~~~~~~~~~~~~~
| | ~~~~~~~~~~~~~~~~~| |clear lcl_bitmap; w =nxt
| | send local_bitmap| |
| | | | +--------+
| | | | +---------->+ |
| | | | |w=next | Error/ |
| | | | |~~~~~~~~ | Abort |
| | | | |Send abort ++-------+
| | v | | ^ w=expct
| | +-+---+--+------+ | & all-1
| | ABORT *<---+ Wait +------+ ~~~~~~~
| | | Next Window | Send abort
| | +-------+---+---+
| | All-1 & w=next & MIC wrong | |
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | +----------------+
| | set local_bitmap(FCN) | All-1 & w=next|
| | send local_bitmap | & MIC right|
| | | ~~~~~~~~~~~~~~~~~~|
| | | set lcl_bitmap(FCN)|
| |All-1 & w=expect & MIC wrong | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| |set local_bitmap(FCN) v +--->* ABORT |
| |send local_bitmap +-------+---+--+ |
| +--------------------->+ Wait End +-+ |
| +-----+------+-+ | w=expct & |
| w=expected & MIC right | ^ | MIC wrong |
| ~~~~~~~~~~~~~~~~~~~~~~ | +---+ ~~~~~~~~~ |
| set local_bitmap(FCN) | set lcl_bitmap(FCN)|
| | |
|All-1 & w=expected & MIC right | |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v |
|set local_bitmap(FCN) +-+----------+ |
+---------------------------->+ END +<----------+
+------------+
--->* Only Uplink
ABORT
~~~~~~~~
Inactivity_Timer = expires
Figure 37: Receiver State Machine for the ACK on error Mode
Appendix D. Allocation of Rule IDs for fragmentation
A set of Rule IDs are allocated to support different aspects of A set of Rule IDs are allocated to support different aspects of
fragmentation functionality as per this document. The allocation of fragmentation functionality as per this document. The allocation of
IDs is to be defined in other documents. The set MAY include: IDs is to be defined in other documents. The set MAY include:
o one ID or a subset of IDs to identify a fragment as well as its o one ID or a subset of IDs to identify a fragment as well as its
reliability option and its window size, if multiple of these are reliability option and its window size, if multiple of these are
supported. supported.
o one ID to identify the ACK message. o one ID to identify the ACK message.
o one ID to identify the Abort message as per Section 9.8. o one ID to identify the Abort message as per Section 9.8.
Appendix D. Note Appendix E. Note
Carles Gomez has been funded in part by the Spanish Government Carles Gomez has been funded in part by the Spanish Government
(Ministerio de Educacion, Cultura y Deporte) through the Jose (Ministerio de Educacion, Cultura y Deporte) through the Jose
Castillejo grant CAS15/00336, and by the ERDF and the Spanish Castillejo grant CAS15/00336, and by the ERDF and the Spanish
Government through project TEC2016-79988-P. Part of his contribution Government through project TEC2016-79988-P. Part of his contribution
to this work has been carried out during his stay as a visiting to this work has been carried out during his stay as a visiting
scholar at the Computer Laboratory of the University of Cambridge. scholar at the Computer Laboratory of the University of Cambridge.
Authors' Addresses Authors' Addresses
 End of changes. 208 change blocks. 
961 lines changed or deleted 1125 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/