[lp-wan] Re: VOICI as SCHC Control Header for 6Lo — invitation to discuss

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

Dear Alex, Marion & Quentin,

Many thanks for reaching out!

We are happy to know that the "SCHC-Lo" draft is being useful to
stress-test the SCHC architecture!

Thanks for your detailed and clear explanation and proposal about VOICI.

Regarding your questions, please find below our responses, focusing on the
multiple end-point scenarios:

- Does this cover all the multiplexing scenarios in the 6Lo draft?

[Response]  Yes.

  - Are there corner cases, especially around multihop (SRO, TRO, PRO,
 Mesh-Under), that VOICI doesn't address?

[Response]  No.

  - Is the 1-byte overhead acceptable, or does the compressed Control
Header provide a meaningfully smaller option?

[Response]  This is the part that we may need to discuss further. Our
current approach supports even a 1-bit over-the-air (compressed) SCHC
Control Header (when there are two SCHC end points per node, as in the
multiple-end point examples shown in the document). Please note that the
whole motivation to propose using SCHC in 6LoWPAN/6Lo environments is
outperforming the traditional header compression mechanisms in 6LoWPAN/6Lo,
therefore we really want to minimize the header overhead to support SCHC to
the extent possible. If a scenario needs to support a very high number of
SCHC end points per node, then the advantage of our current approach blurs.
But we do not foresee such scenario as a very likely one...

Other than that, my personal opinion is that VOICI appears to be a
technically solid and generally applicable design.

We will be happy to continue discussing by whatever means deemed suitable.

Cheers,

Carles (on behalf of the authors)





On Wed, 1 Jul 2026 at 10:35, <[e-mail]> wrote:

> Cc’ing 6lo.
>
> The VOICI draft mentioned below is available here:
> https://datatracker.ietf.org/doc/draft-lampin-voici/.
> Unfortunately the revised architecture document has not yet been
> published, but hopefully it will be ready soon.
> Feel free to contact us for further clarification or to ask any questions.
>
> Best regards,
>
> Alex, Marion & Quentin
>
> *From: *[e-mail] <[e-mail]>
> *Date: *Tuesday, 30 June 2026 at 18:10
> *To: *Carles Gomez Montenegro <[e-mail]>; lp-wan <
> [e-mail]>; schc <[e-mail]>; Ana Minaburo <
> [e-mail]>
> *Subject: *[lp-wan] VOICI as SCHC Control Header for 6Lo — invitation to
> discuss
>
> Hi Carles, Ana, and WG,
>
> We've been working on the revised SCHC architecture document and mapping
> its terminology (Endpoint, Instance, Discriminator, Dispatcher) to the
> concepts in draft-ietf-6lo-schc-15dot4.
> The 6Lo draft provides a really interesting deployment scenario to
> stress-test the architecture, and we would appreciate your feedback.
>
> We think that VOICI (draft-lampin-voici) would be a good candidate to
> serve as  the SCHC Control Header for 802.15.4 deployments. Here is the
> reasoning.
>
> The key idea is simple. The architecture document defines the SCHC Control
> Header as an optional header that carries routing metadata whenever the
> extrinsic Discriminator isn't enough.
> When an Endpoint runs more than one Instance (the "Multiple-end point"
> case in the 6Lo draft), the dispatcher needs an explicit value to route
> each Datagram to the correct Instance.
>
> One possibility is that VOICI embodies the Control Header:
>
>   - The SCHC Dispatch byte signals the presence of a VOICI header
>   - The VOICI Session ID identifies the target Instance
>   - Minimal overhead: 1 byte in the common case (3-bit inline Session ID),
> LEB128 extension for larger spaces
>   - Optional integrity (CRC-16) and original framing recovery come along
> "for free"
>   - For the Single-end point case (one Instance per Endpoint), VOICI is
> absent — the SCHC Dispatch byte alone serves as the extrinsic Discriminator
>
> For the Single-end point case, no change at all.  For Multiple-end point,
> the VOICI header *is* the Control Header on the wire — the Session ID
> provides the Discriminator value the Dispatcher needs.
>
> We're interested to know:
>
>   - Does this cover all the multiplexing scenarios in the 6Lo draft?
>   - Are there corner cases, especially around multihop (SRO, TRO, PRO,
>  Mesh-Under), that VOICI doesn't address?
>   - Is the 1-byte overhead acceptable, or does the compressed Control
> Header provide a meaningfully smaller option?
>
> We're happy to arrange a side meeting or call to talk through this. The
> 6Lo deployment is exactly the kind of scenario the architecture document
> needs to illustrate, and your feedback would be very welcome.
>
> Thanks,
>
> Alex, Marion & Quentin
>
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>