Hi Omar, Sorry for the late response, and many thanks for your comments!
Indeed, a few details about the PRO Header were not sufficiently specified in the previous version of the draft. Please find below my inline responses: On Thu, 22 Oct 2026 at 17:39, omar merroun <[email protected]> wrote: > Hi all, > > I am Omar, a student at IMT Atlantique. I am working on a school > project, with two fellow students and under the supervision of > Laurent Toutain, to implement a SCHC-Lo network using the PRO approach. > > Thank you for this work! While reading the PRO Header section > (Section 4.3 of draft-ietf-6lo-schc-15dot4-13), I came across a few > points I could not resolve on my own from the text : > > 1. Field sizes in the PRO Header: Figure 23 seems to show a 7-bit > Bit Pointer and a 5-bit Address Residue Length, but I could not > find these sizes in the text. Could you confirm them? > Yes, they are confirmed. In -14, we have explicitly added the field sizes as well in the text. > 7 bits would > seem sufficient for the Bit Pointer, since it only needs to skip > the RuleID (RECOMMENDED 1-16 bits from Section 4.1.3) and any > Version residue. > Note that, per RFC 8724 (section 10.1) the IPv6 version is not sent (as we are only considering IPv6, not IPv4). There could be other compression residues as well, but if the only ones are the Hop Limit and the Destination Address residues, the Bit Pointer indeed only needs to skip the RuleID. > > 2. Fields between Traffic Class and Hop Limit: Section 4.3 says the > Hop Limit and destination address residues follow the Traffic > Class residue, and Section 6.1 keeps the other fields in IPv6 > header order. This seems to imply that Flow Label, Payload Length > and Next Header must have zero-length residues (not-sent or > compute-*). Is this a requirement for PRO Rules ? If not, > how does a 6LR locate the Hop Limit residue when the Flow Label > is sent for example? > > 3. Traffic Class residue size: the HLM flag gives the Hop Limit > residue size and the Address Residue Length gives the destination > address residue size, but I found nothing indicating the size of > the Traffic Class residue. Since a router may read and modify the > ECN bits, should the Traffic Class residue always contain at least > the 2 ECN bits (MSB(6) with LSB, or the full 8 bits) ? and what is > expected if Traffic Class is not-sent? Relatedly, Section 3.5.3 > only mentions the Hop Limit and destination address residues as > located by the pointer; so should Traffic Class be added there? > We addressed both your comments 2 and 3 by modifying the PRO Header format. As shown in -14, we have added an ECN field to the PRO Header format, which allows a 6LR to read and modify (if needed) the ECN bits of the compressed packet without the need to store C/D Rules: 0 1 2 3 4 5 6 7 0 1 2 3 4 .... 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 +---------------+-+ - - - +----+-------------+---+-----------+ | SCHC |C| | | | E | Adress | | Pointer |I| DCI |Ctrl| Bit Pointer | C | Residue | | Dispatch |D| | Hdr| | N | Length | +---------------+-+ - - - +----+-------------+---+-----------+ The rest of the Traffic Class field can be handled like the other IPv6 header fields (except for Hop Limit and Destination Address, which have a special handling in PRO). We hope that the updates and responses above will address your comments! Cheers, Carles > Best regards, > Omar >
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
