Subject: Re: [6lo] 6lo and SCHC

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 21 Sep 2020 14:38:47 +0200

Hi Laurent,

Thanks a lot for your comments!

(And sorry for the late response.)

Please find below my inline responses:

> Hi Carles,
>
> Thank you for the draft, it shows that 6lo and SCHC can work together.
> I've
> few comments on the draft:
>
> - NALP
>
> I don't think we should impose the size of the ruleID in 6lo header, for
> instance if a 6lo network is relaying a SCHC packet, it should know the
> rule size to fill the field. if it does not care, it just copy the SCHC
> packet after the NALP.
>
> I will be more in favor of a NALP of 1 byte long then the SCHC packet.

Yes, I agree with your vision.

I just updated the draft. As per this update (-01), a 1-byte Dispatch Type
is (or would be) used for SCHC header compression:
https://datatracker.ietf.org/doc/draft-gomez-6lo-schc-dispatch

This approach exploits the RFC 8025 concept of pages. The current proposal
is allocating a whole page as SCHC Dispatch Type, with the aim to minimize
header overhead.

> We can specify some recommendations at it is currently done for LoRaWAN,
> Sigfox or PPP to carry SCHC packet over 6lo.

Agreed!

One consideration is that the draft focuses only on the use of SCHC header
compression (i.e. not fragmentation), since 6LoWPAN fragmentation was
designed taking into account a set of requirements that is different from
those in LPWAN. In addition, 6LoWPAN fragmentation functionality is being
extended with draft-ietf-6lo-fragment-recovery.

Therefore, I understand that the document that you suggest (e.g. a profile
for SCHC header compression over 802.15.4?) would only focus on the SCHC
header compression part, Rule ID sizes, padding, etc., and not on SCHC
fragmentation.

And the LPWAN WG should probably be involved...

Thoughts?

> - HC
>
> Could be nice to have a HC_SCHC which keeps IPv6 header compression with
> 6lo and allows route-over. Same as for NALP, the SCHC format decoding is
> done by SCHC.

Yes, that is also an interesting approach, probably for a separate document.

Thanks,

Carles (as a WG participant)