Thanks Alex for pointing this out. Again, and perhaps this was not clear in my previous mail, the goal is not to push VOICI as the only option for the control header content. Rather, to stress out the need for a specification of **a** control header to ensure interoperability.
Obviously, this specification can be done per deployment scenario family (this is was I meant by per-profile). Coming back to 6Lo and VOICI, 6Lo and its various network topologies make a great testing ground for the design of SCHC. This is the purpose of this VOICI - 6Lo discussion, not to impose VOICI in 6Lo. I hope I got it right this time 😉. Quentin PS: sorry for the end of mail block of text, I initially described a scenario where multiplexing is required but then felt it was unnecessary as we are all aware of this. The block of text survived my poor proof-reading. From: Alexander PELOV <[email protected]> Date: Thursday, 9 July 2026 at 07:01 To: LAMPIN Quentin INNOV/PTFM <[email protected]> Cc: [email protected] <[email protected]>; Laurent Toutain <[email protected]>; [email protected] <[email protected]>; DUMAY Marion INNOV/PTFM <[email protected]>; lp-wan <[email protected]>; schc <[email protected]>; [email protected] <[email protected]> Subject: Re: [Schc] VOICI as SCHC Control Header for 6Lo — invitation to discuss CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender. ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur. Dear all, The latest SCHC Architecture (-06) allows for everything that -05 version allowed for the SCHC Control Header (and even more). In that aspect, there is no change which is imposed to draft-ietf-6lo-schc-15dot4 Cheers, Alexander On 8 Jul 2026, at 17:53, [email protected] wrote: Thank you all for chiming in. I'd like to discuss the feedback that a dedicated multiplexing header (like VOICI) is unnecessary overhead and explain the rationale. Per §4.3 in -05, when multiple session are needed, the text proposes the introduction of a Control Endpoint. When no extrinsic discriminator is available, the control Endpoint at the sender resorts to the transmission of a SCHC Control Header. The SCHC Control Header itself is left unspecified but the example gives a clear outline of what’s expected: a Session ID, a Protocol ID and CRC. The text further proposes to compress this Control Header, which ultimately produces a Rule ID and compression Residue. Once again, the text does not specify the length of the Rule ID nor does it enforce an encoding. Essentially, it says that the receiver is supposed to know how to interpret the incoming bitstream, using some pre-agreed Context between the sender and receiver. The obvious benefit of this approach is a great flexibility, as the format on-the-wire can be adapted to the use-case. This flexibility comes, however, at the cost of (1) interoperability and (2) complexity. Because the Control Header format is unspecified, each implementation is free to define its own. This breaks interoperability between independent actors. For instance, what if one vendor decides that the Session ID is 10 bits and another chooses 8 bits? What happens if one implementation exchanges the positions of the CRC and Protocol ID? Additionally, the receiver must memorize and synchronize as many Control Contexts as there are senders. When sessions are established dynamically, this brings the issue of dynamically managing those rules (and handling those various header formats). This is the problem that VOICI addresses. Having a Control Header with a standardized format is a way to enforce interoperability when multiple SCHC sessions are multiplexed by independent actors. Regarding the overhead of VOICI, its header content is similar to the one given as example in -05: * a Session ID (3bits in its smallest form), * an optional Ethertype/Protocol ID/Port Number whose size is dictated by the carrier. * a 16bits CRC. * two 1-bit flags to indicate the presence of the integrity check (CRC) and the Ethertype/Protocol ID/Port Number. This leaves us with two fields in need of discussion: - V flag: A simple future-proof argument, keeping the possibility of updating the protocol at the cost of 1 bit. - CI (Content Indicator): Same future-proofing argument, plus the idea that in some cases we could multiplex different contents. SCHC is the #1 candidate (as indicated by its code), others may follow (GHC comes to mind). This could also be used to indicate OAM frames. To be discussed. We can obviously also discuss: - The encoding of the Session ID, as suggested by Alex. - The size of the CRC. - Whether the original carrier field could be encoded in a more compact form if we assume specific ranges of possible values. - The absolute need for the V or CI fields. To address the "overhead" concern directly: In specific use-cases with a single session on a very constrained scenario, there is indeed no need for multiplexing, and thus no need for VOICI, or any Control Header. VOICI is a proposal that aims to balance compactness (1 byte in its smallest form) with functionality for scenarios where multiplexing is required (per profile?). We’d be glad to discuss these options with you. Quentin PS: Laurent, the original name was LMX (Light Multiplexer). I ended up discovering VOICI when I started working on the figures 😉. I guess I got somehow inspired by the OpenSCHC logo. To do so, I'd like to walk through a constrained multi-tenant scenario to demonstrate where the "no VOICI" approach hits a structural deadlock, particularly when leveraging the SCHC Control End-Point model from Architecture -05 (§4.3). Let’s consider the following scenario to understand how and when VOICI makes sense: Suppose we have two Networks hosts owned by different parties, one is running Linux and the other BSD. One of the Host, Hc, assumes the role of the client , the other, Hs, assumes the role of the application server. Two different providers P1 and P2 deploy applications on Hc and Hs: * Application A1 is a CoAP server over UDP port 5683. * Application A2 is a CoAPS server over UDP port 5684. P1 deploys a SCHC context C1 and a Session S1 that compresses A1 traffic, the stratum is UDP and CoAP. P2 deploys a SCHC context C2 and a Session S2 that compresses A2 traffic, the stratum is UDP and CoAPS. In this setup, before SCHC compression, we have frames with following structure : Application 1, targeted by C1. +------------------+-------------------+---------+ | IPv6 (Src=Hc, | UDP (Src=P1, | CoAP | | Dst=Hs) | Dst=5683) | | +------------------+------------------+---------+ Application 2, targeted by C2. +------------------+-------------------+-----------+ | IPv6 (Src=Hc, | UDP (Src=P2, | CoAPs | | Dst=Hs) | Dst=5684) | | +------------------+------------------+-----------+ After compression, without any multiplexing mechanisms, we would have the following: Application 1, compressed with C1 +------------------+------------------------------------------+ | IPv6 (Src=Hc, | SCHC Datagram (Context C1) | | Dst=Hs) | [RuleID | Compressed Residue] | +------------------+------------------------------------------+ Application 2, compressed with C2 +------------------+-------------------------------------------+ | IPv6 (Src=Hc, | SCHC Residue (Context C2) | | Dst=Hs) | [RuleID | Compressed Residue] | +------------------+------------------------------------------+ — > In this case, there is no extrinsic discriminator, we need to resort to resort to multiplexing. With the SCHC Control Header, as defined in Architecture -05 (§4.3). From: Ana Minaburo <[email protected]> Date: Tuesday, 7 July 2026 at 21:26 To: Alexander PELOV <[email protected]> Cc: Laurent Toutain <[email protected]>; [email protected] <[email protected]>; DUMAY Marion INNOV/PTFM <[email protected]>; LAMPIN Quentin INNOV/PTFM <[email protected]>; lp-wan <[email protected]>; schc <[email protected]>; [email protected] <[email protected]> Subject: Re: [Schc] VOICI as SCHC Control Header for 6Lo — invitation to discuss CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender. ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur. 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]<mailto:[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]<mailto:[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> [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<https://www.imt-atlantique.fr/> [LinkedIn IMT Atlantique]<https://www.linkedin.com/school/24772587/>[Instagram IMT Atlantique]<https://www.instagram.com/imt_atlantique/>[Facebook IMT Atlantique]<https://www.facebook.com/IMTAtlantique>[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ 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]
