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> > <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] <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.
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
