Subject: [lp-wan] Review of draft-ietf-lpwan-ipv6-static-context-hc-03

From: Juan Carlos Zuniga <[email-masked]>
Date: Tue, 30 May 2017 20:25:18 +0000

Hello,

Below are my comments on draft-ietf-lpwan-ipv6-static-context-hc-03:

General:

-          Throughout the document it is mentioned that this is a "header" compression mechanism. However, in some cases the baseline principles can also be applied to packet payloads. For that reason, I suggest removing "header" from all instances in sentences that are not specific to the header itself, like the abstract and the introduction, e.g. "This document describes a header compression scheme and fragmentation functionality for IPv6/UDP protocols."

Editorial/Technical:

-          Section 2:

o   Rule ID: An identifier for a rule, SCHC C/D and DEV share the same rule ID for a specific flow.

?  Remove: Rule ID is sent on the LPWAN.

o   Add Field Identifier (FID) definition

o   Add IID, DEV ID, and APP ID definitions (for these two latter, please see comments on sections 6 and 7 below)

-          Section 3:

o   ROHC: Add reference to RFC 5795

o   "The context must be stored in both ends. It can also be learned by using a provisionning protocol that is out of the scope of this draft."

?  Change to >> The context must be stored in both ends, and it can either be leaned by a provisioning protocol, by out of band means, it can be pre-provisioned, etc. The way the context is learned on both sides is out of scope of this document.

o   The principle is the same in the other direction.

?  Change to >> The SCHC process is bidirectional, so the same principles can be applied in the other direction

o   Add a new subsection header (e.g. 3.1) called "SCHC Rules" before the following paragraph:

?  "The context contains a list of rules..."

o   Move the following paragraph to the beginning of the proposed new subsection 3.1:

?  "The main idea of the compression scheme..."

-          Current section 3.2 Packet processing:

o   "compression rule selection: the goal is to identify which rule(s)will be used to compress the headers. Each field is associated to a matching operator for compression. Each header field's value is compared to the corresponding target value stored in the rule for that field using the matching operator. If all the fields in the packet's header satisfied all the matching operators of a rule, the packet is processed using Compression Decompression Function associated with the fields. Otherwise the next rule is tested. If no eligible rule is found, then the packet is sent without compression, which may require using the fragmentation procedure."

?  Change to >> "compression rule selection: the goal is to identify which rule(s) will be used to compress the packet. Fields are first identified according to their field identifier (FID), field position (FP) and direction indicator (DI). 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 satisfy all the matching operators (MOs) of a rule (i.e. all results are True), the fields of the packet are then processed according to the Compression Decompression Actions (CDAs) and a compressed packet is obtained. Otherwise the next rule is tested. If no eligible rule is found, then the packet must be sent without compression, in which case the fragmentation process may be required."

o   Not sure why the following sentence was added from rev 02 to rev 03: "In the downstrean direction, the rule is also used to find the device ID. "

?  Should probably remove the sentence, as it looks out of place.

?  Also, isn't it that in DL first the DEV ID is used to know the rule, as the same rule ID can be used to identify different rules for different devices?

o   "sending: The rule ID is sent to the other end followed by information resulting from the compression of header fields.  This information is sent in the order expressed in the rule for the matching fields.  The way the rule ID is sent depends on the layer two technology and will be specified in a specific document.  For example, it can either be included in a Layer 2 header or sent in the first byte of the L2 payload. (cf.  Figure 3)

?  Change to >> "sending: The rule ID is sent to the other end followed by information resulting from the compression of the packet's fields.  This information 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 technology and will be specified in a specific document.  For example, it can either be included in a Layer 2 header or sent in the first byte of the L2 payload. (cf.  Figure 3)

o   "decompression: The receiver identifies the sender through its device-id (e.g.  MAC address) and selects the appropriate rule through the rule ID. This rule gives the compressed header format and associates these values to header fields.  It applies the CDA action to reconstruct the original header fields.  The CDA order can be different of the order given by the rule.  For instance Compute-* may be applied after the other CDAs.

?  Change to >> "decompression: In the upstream direction, the receiver first identifies the sender through its device identifier (DID) and selects the appropriate rule through the rule ID. This rule gives the compressed header format and associates these values to header fields.  It applies the CDA action to reconstruct the original header fields.  The CDA order can be different of the order given by the rule.  For instance Compute-* may be applied after the other CDAs."

-          Section 4

o   "This document describes basic matching operators (MO)s which must be known by both SCHC C/D, endpoints involved in the header compression/decompression.  They are not typed and can be applied indifferently to integer, string or any other type.  The MOs and their definitions are provided next:"

?  Change to >> "Matching operators (MOs) are functions used by both SCHC C/D endpoints involved in the header compression/decompression.  They are not typed and can be applied indifferently to integer, string or any other data type.  The result of the operation can either be True or False. MOs are defined as follows:"

o   "equal: a field value in a packet matches with a field value in a rule if they are equal."

?  Change to>> "equal: a field value in a packet matches with a TV in a rule if they are equal."

o   "MSB(length): a field value of a size equal to "length" bits in a packet matches with a field value in a rule if the most significant "length" bits are equal."

?  Change to>> "MSB (length): a matching is obtained if the most significant bits of the length field value of the packet are equal to the TV in the rule."

-          Section 5

o   In figure 4 (should probably be called table instead of figure), change the following Action:

?  LSB(length)|send LSB|ctxt value OR rcvd value  >>  LSB(length)|send LSB|TV (OR) received value

o   In 5.4: "LSB action is used to send a fixed part of the packet field header to the other end."

?  Change to>> "LSB action is used to avoid sending the fixed part of the packet field to the other end."

o   5.5.  DEViid-DID, APPiid-DID CDA:

?  "These functions are used to process respectively the Device and the Application Device Identifier (DID).  APPiid-DID CDA is less common, since current LPWAN technologies frames contain a single address.

?  The IID value is computed from the Device ID present in the Layer 2 header.  The computation depends on the technology and the Device ID size.

?  In the downstream direction, these CDA are used to determine the L2 addresses used by the LPWAN."

?  Change to>> DEV ID, APP ID CDAs:

?  "These functions are used to process the DEV and the APP Identifiers.  The value can be computed from the Device ID present in the Layer 2 header.  The computation is specific for each LPWAN technology and depends on the Device ID size.

o   In 5.6 - Add new subsections (5.6.1 and 5.6.2) to the compute-length and compute-checksum function paragraph descriptions, respectively

-          Section 6

o   6.2: wellknown >> well-known

o   6.3: dpending >> depending

o   6.7.2 IPv6 source and destination IID: "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 that case, the TV is not set, the MO is set to "ignore" and the CDA is set to "DEViid-DID" or "APPiid-DID".  Note that the LPWAN technology is generally carrying a single device identifier corresponding to the DEV."

o   Change to>> "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 that case, the TV is not set, the MO is set to "ignore" and the CDA is set to "DEV IID" or "APP IID".  Note that the LPWAN technology is generally carrying a single device identifier corresponding to the DEV."

o   The following paragraph is contradictory:

?  For privacy reasons or if the DEV address is changing over time, it maybe better to use a static value.  In that case, the TV contains the value, the MO operator is set to "equal" and the CDA is set to "not-sent".

?  If we are adding privacy features, the use of long-lasting identifiers should be avoided. It is not clear if in this case it is the source or the destination (compressor or decompressor) that is in charge of changing the identity, and what effect does this have on the CDA.

-          Section 7

o   Figure 6: Context rules (and rest of section 7)

?  Change all instances of "DEViid-DID" >> "DEV IID"

o   Remove the following sentence: "The DEViid-DID value is found in the L2 header."

For comments on Section 8 onwards, I will wait for a new revision of the draft incorporating the potential changes to come after the latest discussions about the fragmentation modes.

Best,

Juan Carlos