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, <[email protected]> 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: *[email protected] <[email protected]> > *Date: *Tuesday, 30 June 2026 at 18:10 > *To: *Carles Gomez Montenegro <[email protected]>; lp-wan < > [email protected]>; schc <[email protected]>; Ana Minaburo < > [email protected]> > *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. > >
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
