Dear all, To answer your question: "do you think VOICI would make sense as a Control Header for your use-case?" -The answer is no, The SCHC Header Control, as described in the penultimate version of draft-architecture, is more flexible, independent of any communication, and can be compressed. The VOICI version adds nothing beyond what has been described in the draft-schc-6lo and the draft-architecture, and besides, it introduces overhead.
Ana On Tue, Jul 7, 2026 at 1:11 PM Alexander PELOV < [email protected]> wrote: > 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 <carles.gomez= > [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]> 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. >>> >>> -- >> Schc mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > > > -- > > Laurent TOUTAIN > Enseignant Chercheur > 02 99 12 70 26 <0299127026> - 06 80 07 59 00 <0680075900> > [image: IMT Atlantique] <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 > [image: LinkedIn IMT Atlantique] > <https://www.linkedin.com/school/24772587/>[image: Instagram IMT > Atlantique] <https://www.instagram.com/imt_atlantique/>[image: Facebook > IMT Atlantique] <https://www.facebook.com/IMTAtlantique>[image: YouTube > IMT Atlantique] <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]
