Subject: Re: [lp-wan] WGLC on SCHC for IPv6 and UDP

From: Juan Carlos Zuniga <[email-masked]>
Date: Mon, 5 Feb 2018 05:15:25 +0000

Dear all,

Please find below my comments on draft-ietf-lpwan-ipv6-static-context-hc-09.

I'm marking with (T) the ones that I consider more technical, or that may require some discussion.

Best,

Juan Carlos

------------------

Abstract (old):

The Static Context Header Compression (SCHC) offers a great level of
flexibility when processing the header fields. SCHC compression is
based on a common static context stored in a LPWAN device and in the
network. Static context means that the stored information does not
change during packet transmission. The context describes the field
values and keeps information that will not be transmitted through the
constrained network.

SCHC must be used for LPWAN networks because it avoids complex
resynchronization mechanisms, which are incompatible with LPWAN
characteristics. And also, because with SCHC, in most cases IPv6/UDP
headers can be reduced to a small identifier called Rule ID. Even
though, sometimes, a SCHC compressed packet will not fit in one L2
PDU, and the SCHC fragmentation protocol defined in this document may
be used.

Abstract (new)

The Static Context Header Compression (SCHC) offers a great level of
flexibility when processing the header fields. SCHC compression is
based on a common static context stored in a LPWAN device and in the
network. Static context means that the stored information defined in the context descriptor does not
change during packet transmission. The context describes the field
values and keeps information that will not be transmitted through the
constrained network.

SCHC is very useful for LPWAN networks because it avoids complex
resynchronization mechanisms, which are incompatible with LPWAN
characteristics. Also, with SCHC in most cases IPv6/UDP
headers can be reduced to a small identifier called a Rule ID. When
a SCHC compressed packet cannot fit in one L2
PDU, the SCHC fragmentation protocol defined in this document may
be used to transmit the PDU over multiple L2 transmissions.

1. Introduction
(old)
Header compression is mandatory...
(new)
Header compression is needed...

(old)
Traffic flows are mostly known in advance since devices embed
built-in applications
(new)
Traffic flows can be known in advance since most LPWAN devices embed
built-in applications

2. LPWAN Architecture
(old)
LPWAN technologies have similar architectures but different
terminology. We can identify different types of entities in a
typical LPWAN network, see Figure 1:
o Devices (Dev) are the end-devices or hosts (e.g. sensors,
actuators, etc.). There can be a high density of devices per radio
gateway.
(new)
LPWAN technologies have similar network architectures but different
terminology. We can identify different types of entities in a
typical LPWAN network, see Figure 1:
o Devices (Dev) are the end-devices or hosts (e.g. sensors,
actuators, etc.). There can be a very high number of devices per radio
gateway.

3. Terminology
(old)
o Dw: Down Link direction for compression, from SCHC C/D to Dev
o FL: Field Length is a value to identify if the field is fixed or
variable length.
o FP: Field Position is a value that is used to identify each
instance a field appears in the header.
o Inactivity Timer. A timer to end the fragmentation state machine
when there is an error and there is no possibility to continue an
on-going fragmented packet transmission.
o Retransmission Timer. A timer used by the fragment sender during
an on-going fragmented packet transmission to detect possible link
errors when waiting for a possible incoming ACK.
o SCHC C/D: Static Context Header Compression Compressor/
Decompressor. A process in the network to achieve compression/
decompressing headers. SCHC C/D uses SCHC rules to perform
compression and decompression.
o Up: Up Link direction for compression, from Dev to SCHC C/D.
(new)
o Dw: Downlink direction for compression/decompression, from SCHC C/D in the network to SCHC C/D in the DEV
o FL: Field Length identifies whether a field has fixed or variable size, and for the latter it indicates its length.
o FP: Field Position is a value that is used to identify the position where each instance of a field appears in the header.
o Inactivity Timer. A timer used at the end of the fragmentation state machine to detect when there is an error and there is no possibility to continue an
on-going fragmented packet transmission.
o Retransmission Timer. A timer used by the fragment sender state machine during
an on-going fragmented packet transmission to detect possible link
errors when waiting for a possible incoming ACK.
o SCHC C/D: Static Context Header Compression Compressor/
Decompressor. A mechanism used both at the Dev and at the network to achieve compression/
Decompression of IP/UDP headers, by using static SCHC rules.
o Up: Uplink direction for compression/decompression, from the Dev SCHC C/D to the network SCHC C/D.

4. Static Context Header Compression
(old)
Static Context Header Compression (SCHC) avoids context
synchronization, which is the most bandwidth-consuming operation in
other header compression mechanisms such as RoHC [RFC5795]. Based on
the fact that the nature of data flows is highly predictable in LPWAN
networks, some static contexts may be stored on the Device (Dev).
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
be pre-provisioned, etc. The way the context is learned on both
sides are out of the scope of this document.
(new)
Static Context Header Compression (SCHC) avoids context
synchronization, which is the most bandwidth-consuming operation in
other header compression mechanisms such as RoHC [RFC5795]. Since the nature of data flows is highly predictable in LPWAN
networks, static contexts may be stored beforehand to omit transmitting some information over the air.
The contexts must be stored at both ends, and they can either be learned by a provisioning protocol, by out of band means, or they can
be pre-provisioned. The way the contexts are provisioned on both ends is out of the scope of this document.

(T)
(old)
Figure 2 represents the architecture for compression/decompression,
it is based on [I-D.ietf-lpwan-overview] terminology. The Device is
sending applications flows using IPv6 or IPv6/UDP protocols. These
flows are compressed by a Static Context Header Compression
Compressor/Decompressor (SCHC C/D) to reduce headers size. The
resulting information is sent to a layer two (L2) frame to a LPWAN
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
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
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
packet can be sent on the Internet to one or several LPWAN
Application Servers (App).
(new)
Figure 2 represents the architecture for compression/decompression,
and it is based on the [I-D.ietf-lpwan-overview] terminology. In the uplink direction, the Device is
sending application flows using IPv6 or IPv6/UDP protocols. These
flows are compressed by a Static Context Header Compression
Compressor/Decompressor (SCHC C/D) to reduce the headers' size. The
resulting information is sent over a layer two (L2) frame to a LPWAN
Radio Network (RG) which forwards the frame to a Network Gateway
(NGW). The NGW sends the data to an SCHC C/D function in the network for decompression. This function
shares the same rules with the Dev. The SCHC C/D can be collocated with
the Network Gateway (NGW), or it can be located in another part of the network, as long as a tunnel is
established between the NGW and the network SCHC C/D function. The SCHC C/D functions on both
sides must share the same set of Rules. After decompression, the
packet can be sent over the Internet to one or several LPWAN Application Servers (App).
The SCHC C/D process is bidirectional, so the same principles can be
applied on the downlink direction.

4.1 SCHC Rules
(old)
The main idea of the SCHC compression scheme is to send the Rule id
to the other end instead of sending known field values. This Rule id
identifies a rule that matches as much as possible the original
packet values. When a value is known by both ends, it is not
necessary to send it through the LPWAN network.
The context contains a list of rules (cf. Figure 3). Each Rule
contains itself a list of fields descriptions composed of a field
identifier (FID), a field length (FL), a field position (FP), a
direction indicator (DI), a target value (TV), a matching operator
(MO) and a Compression/Decompression Action (CDA).
(new)
The main idea of the SCHC compression scheme is to transmit the Rule id
to the other end instead of sending known field values. This Rule id
identifies a rule that matches as much as possible the original
packet values. Hence, when a value is known by both ends, it is only
necessary to send the Rule ID over the LPWAN network.
The context contains a list of rules (cf. Figure 3). Each Rule
contains itself a list of field descriptions composed of a field
identifier (FID), a field length (FL), a field position (FP), a
direction indicator (DI), a target value (TV), a matching operator
(MO) and a Compression/Decompression Action (CDA).
...
(old)
The Rule also describes the compressed header fields which are
transmitted regarding their position in the rule which is used for
data serialization on the compressor side and data deserialization on
the decompressor side.
(new)
The Rule also describes the compressed header fields that are
transmitted and their position in the rule, which is used for
data serialization on the compressor side and data deserialization on
the decompressor side.
...
(old)
o A Field Length (FL) is the length...
(new)
o A Field Length (FL) represents the length...
...
(old)
* BIDIRECTIONAL (Bi) when the field or the value is present
either upstream or downstream.
(new)
* BIDIRECTIONAL (Bi) when the field or the value is present
in both uplink and downlink directions.
...
(old)
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
(integer, strings, etc.). For instance, it can be a single value
or a more complex structure (array, list, etc.), such as a JSON or
a CBOR structure.
(new)
o Target Value (TV) is a value used to make the comparison with
the packet header field. The Target Value can be of any type
(integer, strings, etc.). For instance, it can be a single value, a more complex structure (array, list, etc.), or a JSON or
a CBOR structure.
...
(old)
o A Compression Decompression Action (CDA) is used to describe the
compression and the decompression process. The CDA may require
some parameters, CDA are used in both compression and
decompression phases.
(new)
o Compression Decompression Action (CDA) is used to describe the
compression and the decompression process to be performed after the MO is applied. The CDA may require
certain parameters to be processed. CDAs are used by both compression and
decompression functions.

4.2 Rule ID
(old)
Rule IDs are sent between both compression/decompression elements.
The size of the Rule ID is not specified in this document, it is
implementation-specific and can vary regarding the LPWAN technology,
the number of flows, among others.
Some values in the Rule ID space are reserved for other
functionalities than header compression as fragmentation. (See
Section 5).
Rule IDs are specific to a Dev. Two Devs may use the same Rule ID for
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
find the appropriate Rule.
(new)
Rule IDs are used between the SCHC compression and decompression functions.
The size of the Rule ID is not specified in this document, as it is
implementation-specific and can vary regarding the LPWAN technology,
the number of flows, etc.
Some values in the Rule ID space are reserved for other
functionalities than header compression, such as packet fragmentation. (See
Section 5).
Rule IDs are specific to a Dev. Hence, multiple Dev instances may use the same Rule ID to define
different header compression contexts. To identify the correct Rule ID, the
SCHC C/D needs to correlate the Rule ID with the Dev identifier to
find the appropriate Rule to be applied.

4.3 Packet processing
(T)
(old)
o compression Rule selection: The goal is to identify which Rule(s)
will be used to compress the packet's headers. When doing
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
Dev, only the Rule-ID may be used. The next step is to choose the
fields by their direction, using the direction indicator (DI), so
the fields that do not correspond to the appropriated DI will be
excluded. Next, then the fields are identified according to their
field identifier (FID) and field position (FP). If the field
position does not correspond, then the Rule is not used and the
SCHC take next Rule. Once the DI and the FP correspond to the
header information, each field's value is then compared to the
corresponding target value (TV) stored in the Rule for that
specific field using the matching operator (MO). If all the
fields in the packet's header satisfy all the matching operators
(MOs) of a Rule (i.e. all results are True), the fields of the
header are then processed according to the Compression/
Decompression Actions (CDAs) and a compressed header is obtained.
Otherwise, the next rule is tested. If no eligible rule is found,
then the header must be sent without compression, in which case
the fragmentation process must be required.
(new)
o Compression Rule selection: The goal is to identify which Rule(s)
will be used to compress the packet's headers. When doing
compression at the network side the SCHC C/D needs to find the correct
Rule to be used by identifying its Dev-ID and the Rule-ID. At the
Dev side, only the Rule-ID may be used, since there is only one possible SCHC C/D destination function
(at the network). The next step is to choose the
fields by their direction, using the direction indicator (DI), so
the fields that do not correspond to the appropriated DI can be
excluded. Next, the fields are identified according to their
field identifier (FID) and field position (FP). If the field
position does not correspond too the one of the Rule ID, then the Rule is not used and the
SCHC SHALL proceed to the next Rule. Once the DI and the FP correspond to the
header information, each field's value is then compared to the
corresponding target value (TV) stored in the Rule for that
specific field using the matching operator (MO). If all the
fields in the packet's header satisfy all the matching operators
(MOs) of a Rule (i.e. all results are True), the fields of the
header are then processed according to the Compression/
Decompression Actions (CDAs) and a compressed header is obtained.
Otherwise, the next rule is tested with its MOs. If no eligible rule is found,
then the header must be sent without compression, in which case
the fragmentation process MAY be required.

(old)
o sending: The Rule ID is sent to the other end followed by the
information resulting from the compression of header fields,
directly followed by the payload. The product of field
compression is sent in the order expressed in the Rule for 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 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
the first byte of the L2 payload. (Cf. Figure 4).
(new)
o Sending: If an eligible Rule is found, the Rule ID is sent to the other end followed by the
information resulting from the compression of header fields,
and directly followed by the payload. The product of field
compression is sent in the order expressed in the Rule for the
matching fields. The way the Rule ID is sent depends on the
specific LPWAN layer two technology. For
example, it can be either included in a Layer 2 header or sent in
the first byte of the L2 payload. (Cf. Figure 4).
This process will be specified in a LPWAN technology-specific document and is out of the scope of the present document.

(T)
(old)
+--- ... --+-------------- ... --------------+-----------+--...--+
| Rule ID  |Compressed Hdr Fields information| payload   |padding|
+--- ... --+-------------- ... --------------+-----------+--...--+
Figure 4: LPWAN Compressed Format Packet
(new)
+--- ... --+-------------- ... --------------+---------+----...---+
| Rule ID  |Compressed Hdr Fields information| payload | padding  |
|          |                                 |         |(optional)|
+--- ... --+-------------- ... --------------+---------+----...---+
Figure 4: LPWAN Compressed Format Packet

4.4 Matching operators
(T - assuming this MO can be made more generic than only applicable to the length field)
(old)
o MSB(length): A matching is obtained if the most significant bits
of the length field value bits of the header are equal to the TV
in the rule. The MSB Matching Operator needs a parameter,
indicating the number of bits, to proceed to the matching.
(new)
o MSB: A matching is obtained if the most significant bits
of the field value bits of the header are equal to the TV
in the rule. The MSB Matching Operator needs a parameter,
indicating the number of bits, to proceed to the matching.

(old)
o match-mapping: The goal of mapping-sent is to reduce the size of a
field by allocating a shorter value. The Target Value contains a
list of values. Each value is identified by a short ID (or
index). This operator matches if a field value is equal to one of
those target values.
(new)
o match-mapping: The goal of match-mapping is to reduce the size of a
field by allocating a shorter value. The Target Value contains a
list of values. Each value is identified by a short ID (or
index). This operator matches if a field value is equal to one of
those target values.

(old)
/--------------------+-------------+----------------------------\
| Action | Compression | Decompression |
| | | |
+--------------------+-------------+----------------------------+
|not-sent |elided |use value stored in ctxt |
|value-sent |send |build from received value |
|mapping-sent |send index |value from index on a table |
|LSB(length) |send LSB |TV OR received value |
|compute-length |elided |compute length |
|compute-checksum |elided |compute UDP checksum |
|Deviid |elided |build IID from L2 Dev addr |
|Appiid |elided |build IID from L2 App addr |
\--------------------+-------------+----------------------------/
Figure 5: Compression and Decompression Functions
(new)
/--------------------+-------------+----------------------------\
| Action | Compression | Decompression |
| | | |
+--------------------+-------------+----------------------------+
|not-sent |elided |use value stored in ctxt |
|value-sent |send |build from received value |
|match-mapping |send index |value from index on a table |
|LSB |send LSB |TV OR received value |
|compute-length |elided |compute length |
|compute-checksum |elided |compute UDP checksum |
|Deviid |elided |build IID from L2 Dev addr |
|Appiid |elided |build IID from L2 App addr |
\--------------------+-------------+----------------------------/
Figure 5: Compression and Decompression Functions

4.5.2 value-CDA
(old)
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
compressed message header. Both Compressor and Decompressor must
know the size of the field, either implicitly (the size is known by
both sides) or explicitly in the compressed header field by
indicating the length. This function is generally used with the
"ignore" MO.
(new)
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
compressed message header. Both Compressor and Decompressor must
know the size of the field, either implicitly (the size is known by
both sides) or explicitly in the compressed header field by
indicating the length, as defined in section 4.5. This function is generally used with the
"ignore" MO.

4.5.4 LSB CDA
(old)
The compressor sends the "length" Least Significant Bits. The
decompressor combines the value received with the Target Value.
(new)
The compressor sends the Least Significant Bits (e.g. LSB of the length field). The
decompressor combines the value received with the Target Value.

4.5.5 DEViid, APPiid CDA
(old)
The IID value may be computed from the Device ID present in the Layer
2 header. The computation is specific for each LPWAN technology and
may depend on the Device ID size.
(new)
The IID value MAY be computed from the Device ID present in the Layer
2 header, or from some other stable identifier. The computation is specific for each LPWAN technology and
MAY depend on the Device ID size.

5.1 Fragmentation overview
(old)
LPWAN technologies impose some strict limitations on traffic, (e.g.)
devices are sleeping most of the time and may receive data during a
short period of time after transmission to preserve battery. To
adapt the SCHC fragmentation to the capabilities of LPWAN
technologies, it is desirable to enable optional fragment
retransmission and to allow a gradation of fragment delivery
reliability. This document does not make any decision with regard to
which fragment delivery reliability option(s) will be used over a
specific LPWAN technology.
(new)
LPWAN technologies impose some strict limitations on traffic. For instance,
devices are sleeping most of the time and may receive data during a
short period of time after transmission to preserve battery. To
adapt the SCHC fragmentation to the capabilities of LPWAN
technologies, it is desirable to enable optional fragment
retransmission and to allow a gradation of fragment delivery
reliability. This document does not make any decision with regard to
which fragment delivery reliability option(s) will be used over a
specific LPWAN technology. These details will be defined in other technology-specific documents.

5.2 Functionalities
(old)
This subsection describes the different fields in the fragmentation
header frames (see the related formats in Section 5.4), as well as
the tools that are used to enable the fragmentation functionalities
defined in this document, and the different reliability options
supported.
(new)
This subsection describes the different fields in the fragmentation
header frames (see the related formats in Section 5.4). It also describes
the tools that are used to enable the fragmentation functionalities
defined in this document, and the different reliability options
supported.
...
(old)
Message Integrity Check (MIC) ...
Nevertheless, other algorithm MAY be mandated in the corresponding
technology documents (e.g. technology-specific profiles).
(new)
Message Integrity Check (MIC) ...
Nevertheless, other algorithms MAY be required in other
LPWAN technology-specific documents (e.g. technology-specific profiles).

(old)
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.
(new)
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.
A value of 1 represents a positive MIC calculation at the receiver side.

(T)
(discussion)
O Bitmap ...
However, the
sending format of the Bitmap will be truncated until a byte
boundary where the last error is given
[JCZ] I believe we decided not to limit the protocol to byte boundaries.

(T)
(discussion)
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.
[JCZ] same comment about not limiting the protocol to byte boundaries.

5.3 Delivery reliability options

o No ACK.
(add reference to 5.5.1 at the end of the paragraph)

o Window mode - ACK always (ACK-Always).
(old)
In ACK-always,an ACK is transmitted by the fragment receiver after a
window of fragments has been sent.
(new)
In ACK-always, an ACK is transmitted by the fragment receiver every time a window of fragments has been received.
(add reference to 5.5.2.1 at the end of the paragraph)

o Window mode - ACK-on-error (ACK-on-error).
(old)
One exception to this behavior is in the last
window, where the receiver MUST transmit an ACK, even if all the
fragments in the last window have been correctly received.
(new)
One exception to this behavior is in the last
window, where the receiver MUST transmit an ACK, including the MIC calculation result, even if all the
fragments in the last window have been correctly received.
(add reference to 5.5.2.2 at the end of the paragraph)

5.4.1 Fragment format
(old)
+-----------------+-----------------------+---------+
| Fragment Header | Fragment payload | padding |
+-----------------+-----------------------+---------+
Figure 6: Fragment format.
(new)
+-----------------+-----------------------+-----------+
| Fragment Header | Fragment payload      |  padding  |
|                 |                       | (optional)|
+-----------------+-----------------------+-----------+
Figure 6: Fragment format.

5.5 Baseline mechanism
(old)
... In all modes, the last fragment of a packet must contains a
MIC which is used to check...
(new)
In all modes, the last fragment of a packet must contain a
MIC which is used to check

5.5.2 The Window modes >> Window modes

6. Padding management
(old)
SCHC header, either for compression, fragmentation or acknowledgment
does not preserve byte alignment. Since most of the LPWAN network
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.
(new)
SCHC header, either for compression, fragmentation or acknowledgment
does not preserve byte alignment. Since in some LPWAN network
technologies payload is expressed in an integer number of bytes; the
sender can introduce at the end some padding bits while the receiver
must be able to eliminate them.

7.7.2 IPv6 source and destination IID

(T)
(old)
...
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
operator is set to "equal" and the CDA is set to "not-sent".

(new)
...
For privacy reasons or if the DEV address is changing over time, a static value that is not equal to the DEV address SHOULD be used.  In that case, the TV contains the static value, the MO operator is set to "equal" and the CDF is set to "not-sent". RFC 7217 provides some methods that MAY be used to derive this static identifier.

From: lp-wan [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: December 22, 2017 11:19 AM
To: lp-wan <[email-masked]>
Subject: [lp-wan] WGLC on SCHC for IPv6 and UDP

Dear WG:

As discussed during the last interim, we are starting a WGLC on the "LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP" document:

https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/

This is a fundamental work for the WG, so please, DO review the document and DO provide your comments and remarks if you see any issues.

In order to cover the season break, this WGLC will end in three+ weeks, on January 15th, 2018, 23h55 CEST, right before our next interim meeting.

Best,

Pascal and Alexander

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 5 Feb 2018 16:00:09 +0000

Hello Juan-Carlos and authors:

Thanks a bunch Juan Carlos for the in depth review!

On the abstract, I still find it long and not to the point...

Abstract (old):

Abstract (new)

[Pascal] I'd remove the first sentence of the first paragraph and second paragraph in its entirety.
Instead, I'd add one sentence indicating that fragmentation with optional fragment recovery is provided to support MTU required by IPv6.

Cheers,

Pascal