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

[Carles Gomez Montenegro <[e-mail]>]

Dear Georgios,

Many thanks for your comments and proposals!

Please find below my inline comments/responses (as a co-author):

On Fri, 15 Dec 2023 at 14:04, Georgios PAPADOPOULOS <
[e-mail]> wrote:

> 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.
>
>
Leveraging on your analysis, I understand that there are the following pros
and cons:

- Pros: your proposal allows to support multiple destination prefixes (with
no additional overhead in single-prefix scenarios) in a way significantly
more efficient than the current one.

- Cons: the destination prefix context (i.e., not SCHC C/D Rules) has to be
distributed to the 6LRs, and possibly, maintained. (There are also the 4
additional bits of packet header overhead.)

I personally like that the cons above only exist when multiple destination
prefixes need to be handled.

What does the WG think regarding Georgios' proposal?  Any comments?



> 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.
>
>
>
The current SCHC Pointer format is as follows:

                   0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
                  +-+-------------+-+-------------+
                  |R|    Bit      |0|   Address   |
                  | |   pointer   | |   length    |
                  +-+-------------+-+-------------+

There are two currently unused bits (the 'R' bit and the '0' bit). Perhaps
one of them could be defined as CID.


> 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.
>
>
Yes, this is a current limitation of PRO. There may be different
alternatives to expose the Hop Limit field to a 6LR in this case, including
compressed ones. Let's think about it...


>
> 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?
>
>
Agreed!

In my opinion, we need to state this in the document.

Once again, many thanks!

Cheers,

Carles