Dear Laurent, Carless, all, I think the question was mostly intended in the sense “do you think VOICI would make sense as a Control Header for your use-case”.
The idea is that there is an (optional) SCHC Control Header which can be specified at will. Quentin has identified that there are several uses of the Control Header which are seen often, e.g. multiplexing, CRC, etc. and has designed a very compact protocol, which anyone can choose to use as their SCHC Control Header, if needed.- From your answers, I get the feeling that this is not the case for 6lo. We can discuss that more in details of course - and maybe you’ll discover that it is useful :) Cheers, Alexander > On 6 Jul 2026, at 09:38, Laurent Toutain <[email protected]> wrote: > > Hi SCHC lovers, > > Sorry for not reacting earlier, but I thought this draft concerned only PPP > links. VOICI seems to cover the same scope as the SCHC control header, > including CRC, Next Header authentication and adding some multiplexing > capability if end-points cannot be directly identify though discriminators. > For me this proposal breaks some design characteristics of SCHC. No document > imposes a size; the context provides the size. This applies to the Rule ID > and also to fragmentation header fields. This is for me very important allow > SCHC to run on any kind of media. We are currently working on very > constrained media such as underwater communication, where every bit counts. > Losing space to signal something I don't use makes this proposal unusable. > For instance I don't understand the need for a version bit except for the > acronym :-) Why 1 bit, why not 2. What happens with unexpected values? SCHC > is a point-to-point association so this can be present in the rule, not on > the wire. > > SCHC control header allows adapting the control header to the capability of > the link and the application, so in my views, it is more flexible than a > wired format. I would like to see why you consider VOICI more adaped the SCHC > control header. > > Laurent > > On Sun, Jul 5, 2026 at 9:12 AM Carles Gomez Montenegro > <[email protected] <mailto:[email protected]>> > wrote: >> 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] >> <mailto:[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] <mailto:[email protected]> >>> <[email protected] <mailto:[email protected]>> >>> Date: Tuesday, 30 June 2026 at 18:10 >>> To: Carles Gomez Montenegro <[email protected] >>> <mailto:[email protected]>>; lp-wan <[email protected] >>> <mailto:[email protected]>>; schc <[email protected] <mailto:[email protected]>>; Ana >>> Minaburo <[email protected] <mailto:[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. >> -- >> Schc mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > > > > -- > > Laurent TOUTAIN > Enseignant Chercheur > 02 99 12 70 26 <tel:0299127026> - 06 80 07 59 00 <tel:0680075900> > <https://www.imt-atlantique.fr/> > Une école de l'IMT <https://www.imt.fr/> > Technopôle Brest-Iroise CS 83818 29238 Brest Cedex 3 > La Chantrerie 4 rue Alfred Kastler CS 20722 44307 Nantes Cedex 3 > 2, rue de la Châtaigneraie CS 17608 35576 Cesson Sévigné Cedex > www.imt-atlantique.fr <https://www.imt-atlantique.fr/> > <https://www.linkedin.com/school/24772587/> > <https://www.instagram.com/imt_atlantique/> > <https://www.facebook.com/IMTAtlantique> > <https://www.youtube.com/c/imtatlantique> > Toute l'actualité scientifique de l'IMT : I'MTech <https://imtech.imt.fr/>-- > Schc mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
