Hi Esko, Once again, thanks a lot for such a detailed review! Also, the Thread perspective is extremely valuable.
Please find below our inline comments/responses: On Tue, 21 Oct 2025 at 13:20, Esko Dijk <[email protected]> wrote: > > Hi all, > > Below is a review of draft-ietf-6lo-schc-15dot4-11, from the perspective > of (potentially) applying SCHC to a Thread mesh network. > > First, a few overall (high-level) comments: > > 1. Section 3.5 states that 6LoWPAN defines two approaches: Route-Over and > Mesh-Under. I'm noting that the RFC that introduces these (6606) is > informational; and I wouldn't assume that every 6LoWPAN based network must > fit in one of these two categories. > Thread happens to not fit exactly in these boxes: it uses a hybrid > approach. It has the property of route-over that link-local communications > spans a single radio hop only, never more. On a part of the route in the > mesh network it has the property of mesh-under that a packet can hop > multiple radio hops using only a single IP hop; > where IPv6 packet fragments are forwarded independently without reassembly > at each radio hop. So it could be useful I think to update the document to > take such 6LoWPAN hybrids into account. It would not cause any change in > the solution itself, I think. > Every Thread router can be an ingress point into the mesh-under routing, > so will have to be able to behave like a (route-over) 6LBR - even if it > sometimes performs mesh-under routing actions. > > Agreed! In the next revision, we will explain that hybrid approaches may and do exist. > 2. In all topology examples in Sections 3.5.x, I see the 6LRs and 6LBRs > and mesh-under forwarders are never involved in any application > communication i.e. in a "host" role. > This is conceptually okay, as a 6LR or 6LBR as defined for 6LoWPAN is > purely a routing role. But in practical networks, these roles are often > combined with "host" role - so that a node doing 6LR tasks for example also > sends and receives application messages itself. > This makes the topology examples look nice and clear, but it also makes > them look "too ideal" in a way. This could be resolved by a remark at the > start of 3.5, that in practice these roles might be combined: that would > keep the examples readable and clear. > > Agreed! Yes, the examples are intentionally idealized for clarity. But indeed, giving a remark as you suggest will allow to provide readers with a more realistic view. > 3. Some 6LoWPAN mesh topologies may be statically defined. But in general, > mesh topologies could dynamically change during operation due to changing > radio conditions, people/object motion, or motion of the nodes themselves. > These "dynamics" is the reason why mesh topologies get applied, very often. > There's no upfront knowledge which routing path a packet from A to B will > take then. Thread is designed for such dynamics. For example, a host (6LN) > not participating in the routing protocol may at some point enable its > routing function and become a 6LR. This is done automatically based on > demand and/or topology or RF changes. > For the SRO topology 3.5.1, there's already the requirement that 6LR/6LBR > must store all Rules in use by any nodes in the mesh. For the Thread case > when a 6LN becomes a 6LR this still holds - how this requirement is > satisfied would be in scope of the Thread specification: e.g. configure all > 6LRs and potential-6LRs with the rules upfront, or have a rule distribution > protocol in place, etc. > -> Maybe it's worth specifying that such dynamics can exist. For the SRO > case and mesh-under, the existing definition can handle this. > Agreed! Precisely due to the dynamics that you describe, SRO requires all routers to store all the Rules used in the network. > For other cases TRO/PRO : can there be dynamic changes also in the routing > graph and does the current solution/definition handle these? > > In TRO, dynamic changes would be handled by RPL. In PRO, such changes would be handled by the routing protocol being used. In either TRO or PRO, routers do not need to know the Rules to be able to route packets towards their destination. So yes, both TRO and PRO support dynamic changes (as long as the routing protocol operates correctly). > 4. In the PRO (3.5.3) approach, how would a 6LR be able to change the ECN > bits in the IPv6 packet? As I understand it can only change (decrement) the > Hop Limit field. For changing anything else, it would need to know the > Rules that were applied. > Thread is using the ECN bits: 6LRs/6LBRs can set these in case of > congestion experienced i.e. a rather full packet buffer. Of course Thread > mesh doesn't fit in the 3.5.3 approach; and Thread doesn't use RPL. > It may be the case for RPL that it never uses the ECN bits; however > Section 4.5.3 now says that it can also support protocols other than RPL. > These protocols (or future ones) could be wanting to use the ECN bits? > > Very good point! We need to discuss whether and how TRO or PRO can support changing the ECN bits, and the corresponding possible loss of header compression potential. Both TRO and PRO would require a header format update. > 5. There is in the draft mainly (only?) a focus on the SCHC Rules used for > application communication. Besides this host-to-host communication, there's > also other ongoing communication like management traffic which can benefit > from SCHC compression as well. It could be link-local, or higher-scope (IP) > messages. > Thread uses both link-local and mesh-local IPv6 management messages > which are all 6LoWPAN-compressed. > - for example, in figs 8/9 there are no Rules mentioned that would > operate only on the 6LRs/6LBR. > - or in figs 10/11/13/14/15 there are some nodes (6LR/m) that have no > Rules at all, which seems either inefficient or a simplification of reality. > - Section 7 touches this topic a bit but appears isolated from other > sections without cross-links being made. > > Maybe this could be solved by text explaining how to deal with Rules for > (mesh) management messages? Not sure if this would apply to the pure-RPL > case. But even in a RPL network there could be other management protocols > active at the same time. > > Yes, this is related with the previous comment that 6LR/6LBR are kept "idealized" in the descriptions. One consideration is that, as of today, there exist specifications defining how SCHC can be used to compress some protocol headers, while others have not been yet defined, or have been partially defined (e.g., there is on-going work on how SCHC can be used to compress ICMPv6 packet headers, but not a full description of how Neighbor Discovery messages can be compressed with SCHC). We can possibly add some content regarding management messages, but some of the functionality might need to be out of scope for this document (or for future work). > 6. Layout: It looks like some of the diagrams are already too wide for > easy viewing on the web/HTML-rendered version - a horizontal scrollbar > appears often. > Maybe worth trying aasvg rendering on all of the ASCII diagrams? That > makes the figures better readable on the HTML rendered versions. > > We'll try to improve the figures! > 7. In Section 2.2: "In this document, as in RFC 9008, 6LN acts as a leaf." > - This definition needs a closer look. For example in Figure 3/4 we have > a 6LN communicating with the internet. This 6LN could be a 6LR as well. > There's no need to constrain it to leaves only. > - The term "leaf" is undefined in scope of this draft; maybe we should > avoid the term if it comes from RPL - at this point in the document, RPL > routing is not guaranteed, it's supposed to be generic over all possible > 6LoWPAN routing protocols. So we may avoid "leaf" here and use e.g. "host" > as defined in RFC 6606. > - And e.g. in Section 3.5.2, 6LNs can send packets, in by this definition > a 6LR can't send a packet? That would be constraining. It also links to my > point 2. above. > > > Agreed. First of all, "In this document" may have to be updated to apply only to RPL-based functionality. In any case, we need to make sure that routers can still be the source or a destination of a packet. > > Also below a few more minor / specific text comments: > > - Some "see 3.3.3" mentions - no such section is defined. 3.5.3 ? > > Yes, it should have been "3.5.3". > - Reference [draft-ietf-schc-arch] not defined. There's also a > [draft-ietf-schc-architecture] > > Agreed. > - Sections 3.2.2 and 3.2.3 > In both cases, the second paragraph seems to repeat information from the > 1st paragraph but slightly different. > Is this intentional? If yes I can take a closer look to trying to > understand this. If not intended, then I'll await new text. > > Yes, this is intentional! This relates with SCHC architecture concepts, as follows. There is a SCHC Stratum (atop 802.15.4 and below IPv6). There is only one SCHC Stratum Header end point in either case. In the second case (Multiple-end point networks), the SCHC Stratum Header indicates which is the SCHC Payload end point used for C/D (e.g., so that a receiver knows how to decompress a packet). Note that the SCHC Stratum Header itself is also compressed. In the first case (Single-end point networks), there is only one possible SCHC Payload end point. Conceptually, this is equivalent to the SCHC Stratum Header being fully elided, and having a Rule to decompress the SCHC Stratum Header implicitly known at the receiver. The related concepts are defined in the SCHC architecture draft, in particular, of interest are Fig. 1 and sections 4.3 and 4.4: https://www.ietf.org/archive/id/draft-ietf-schc-architecture-04.txt (Note that a -05 was recently posted, which modifies the related terminology, and we are awaiting the new terms to become stable to update them as well in the SCHC-Lo draft...) > - 3.5.2 > "A 6LR is relieved to store Rules used by nodes that do not include the > 6LR itself." > -> sentence could be clarified. One might read "nodes that do not include > the 6LR" which leads to confusion. > Maybe it's about Rules that are never used by the 6LR itself, either as a > source (compressing) or destination (decompressing) ? > Not fully sure about the intended statement here. > > Yes, the intended statement is about Rules that are never used by the 6LR itself. We'll update the text accordingly. > - Figures 8,9,10,11: doesn't host E also need a rule e.g. Rule 3 ? This > could be required if the CoAP header inside the DTLS session is compressed, > or in the OSCORE case. > Maybe all examples are designed to rule out such compression in packets > going to/from host E? If so, it would be good to clarify it somewhere in > Section 3.5 at the start. > Or maybe in such a case with decompression happening on host E, the Rule > for that would need to be a separate rule from Rule 3 because the > decompression happens in a different SCHC stratum (?) > > Agreed. These figures refer to Rules intended for IPv6 (and/or joint IPv6 plus upper layers) header compression. We can clarify it by adding explicit text, and also perhaps add some separate Rules when C/D happens also at other SCHC Strata. > - 3.5.3 > "In a PRO Multiple-end point network, a not fully compressed SCHC Stratum > Header MUST be used" > -> just for my understanding, is it correct that the administrator / > configuring entity is responsible to ensure that this MUST condition is met? > That is, if a node is for example only using one SoR itself, it still MUST > be configured in a way that it does not use a fully compressed SCHC Stratum > Header? > (This allows intermediate routing nodes to select the right SoR. Otherwise > they wouldn't know which SoR to select.) > > The simplest approach is that the answer to your second question is "yes". This is because perhaps that node will send packets to a destination node which supports more than one SCHC Payload end point, and the latter will need to know which SCHC Payload end point has to be used to decompress a received packet header. > - 3.5.4 > "a fully compressed SCHC Stratum Header MAY be used as long as it is > possible to determine the SCHC Payload end point needed to decompress a > SCHC-compressed packet based on the packet source identifier (which is > present in the Mesh-Under header [RFC 4944])." > -> the correct name here is "mesh header" I think. (Or "Mesh Header" or > "Mesh header" or "Mesh addressing header" - 4944 isn't consistent.) > And "source identifier" should be "originator address" here in RFC 4944 > terms. > Both agreed! > -> just to check my understanding - is the originator address from the > mesh header used here because the IPv6 source address is not available > (yet) at this point in time? > Exactly! > Because I typically would expect it is compressed in some way, at the > moment of packet reception. > In the case of highest compression it could even be compressed to 0 bits > and then the originator address is used to pick the SCHC Payload end point > and later on used again to decompress the IPv6 address according to a rule > that maps originator address to IPv6 address. > > If there is only one possible IPv6 packet header (i.e., combination of header field values), yes! > Related to this, for the Thread case there are these specific behaviors: > - Mesh address of nodes can change over time. For example, when a node > reboots or loses connections to the mesh and later reconnects again. It's > previous 16-bit mesh address could have been claimed already by another > node, that joined the mesh network, in the meantime. This makes it > infeasible to use the mesh originator address for the purposes as defined > above. > Very interesting insight. We may need to add text to explain that this might happen... > - So in this case it would use a not-fully-compressed SCHC Stratum > Header. The stated requirement is still valid in this case, so no text > change is required I think. Just wanted to highlight this! > OK, thanks! > > - 4.3 > About the defined DCI field -> it may be beneficial to define the DCI > field context bits to mean the same as the 6LoWPAN CID configuration bits. > This allows a single configuration of 6lo contexts, which are shared > between 6lo/6lowpan compression and SCHC-low compression when applied > within a single network. > (E.g. some nodes could be older and not support SCHC but support only > 6LoWPAN. These nodes can still use the same compressed prefixes table.) > > > So it's still out of scope how the values are configured, but we can > require with a MUST (or SHOULD?) that these are the same as the related > 6lo/6lowpan CIDs that may be configured already in some existing/known way. > For example: Thread configures CIDs using a known/existing mechanism. > > Indeed! This will be a useful addition to the next revision. > - 4.3 > Address Length field: value can be 0-127. > Is value 127 intended to identify a 128-bit IPv6 address? > This isn't specified currently. And what would value 0 identify, a 1-bit > address residue or an elided address of 0 bits? > Could the 6LR routers do anything useful for routing the packet given a > 0-bit or 1-bit address residue? > Sorry I'm not fully up to date with the SCHC residue concept here - I was > assuming these would be the LSB lower bits of the 128-bit address. While > the higher bits are determined by the DCI selection or the default context > ID (CID) in case the DCI field is absent. > Agreed, Address Length field values and their meaning need to actually be specified, and this field alone does not allow to specify both a residue of 128 bits and a residue of 0 bits... We will come back with a proposal. > > - Sections 5 and 6: didn't look in detail here yet. > > best regards, > Esko > > Once again, many many thanks for such a detailed and useful review! Cheers, Carles and Ana > > -- > *IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6 > 2385 8339 > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Libre de virus.www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
