[6lo] SCHC over 6lo: Pointer-based Route-Over (PRO)

[Georgios PAPADOPOULOS <[e-mail]>]

Dear 6lo,

Below you will find some thoughts and propositions on the PRO approach in SCHC over 6lo draft, i.e., draft-ietf-6lo-schc-15dot4-04.

Many thanks in advance,
Georgios

— — 

1. PRO approach in a network beyond a single prefix:
If the nodes operate in a network beyond a single prefix and are based PRO approach, for the intermediate nodes (i.e., 6LR nodes) that store no Rules, based on the current state of the draft, PRO does not provide much of compression benefit, since in each packet both IPv6 Prefix and IID should be explicitly indicated. In other words, the whole 16 Bytes (128 bits) of the IPv6 destination address will have to be “residue" in the SCHC Header.

One might consider then TRO as an alternative approach, then what if we are in a typical Smart Metering application where there are more than a few hops, i.e., 10 or even 20 hops, from the source to the Root in a multi-hop mesh network?

Therefore, I was wondering why not to consider to employ the benefits of the RFC 6282 while the 6LRs will not store any Rule, and more specifically the notion of the Contexts.
RFC 6282 comes with CID flag, if this flag is active, then after the IPHC header (after the DAM field), an additional 8-bit CID field immediately follows, which allows up to 16 source and destination prefixes.
For the case of PRO, I was thinking to keep only the 4 bits, since PRO considers only the destination IPv6 address.

Therefore, adding contexts as in RFC 6282 would allow to deal with the problem of supporting multiple possible destination prefixes in PRO. As previously presented, the additional overhead would still appear to be low which will probably make it worth. Furthermore, CID could be equal to "0" by default in a scenario where there is one single prefix, for better compression performance, and thus, no need to carry the extra 4 bits of the CID field.

Now, the question is where to locate the CID flag and the CID field of 4 bits. Below, I have a naive approach, I am sure a better one may come up, i.e., extension of the SCHC Pointer size in order to have a second pointer to indicate the CID, see Figure 1.

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
| SCHC Ptr Dsptch | Extended SCHC Pointer | Cmprd Header: IID + Optional CID field | Payload | Padding |
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Figure 1: Frame format for SCHC-compressed packets in PRO.


2. IPv6 Header
Next, in the current state of PRO, the 6LRs can read only the IPv6 destination address, and nothing else.
However, as it is stated in the draft “PRO is compatible with RPL storing mode, as well as with other routing protocols.”, if other fields from the IPv6 header field is required by a 6LR that runs on a XYZ routing protocol, then these devices are not capable to read these fields.

For example, Hop Limit field, it is an essential information for a packet to be dropped in case it ended up in a loop.
Therefore, as an option, we could consider for the Hop Limit field to be followed in the “residue” after the IPv6 destination address.


3. SCHC Pointer Format
Next, considering that in PRO approach the 6LR nodes do not store Rules, then, the Matching Operators of SCHC can not be applied. For instance, the Match-mapping can not be applied as the 6LR needs to have all the potential addresses in order to apply the C/D Action properly.

Therefore, based on the current state of the draft, do we agree that 6LR devices with PRO approach enabled, they do not proceed with any SCHC C/D and any Matching Operation, except reading the destination IPv6 address which is the “residue” in the SCHC Header?