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.
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.
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. For other
cases TRO/PRO : can there be dynamic changes also in the routing graph
and does the current solution/definition handle these?
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?
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.
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.
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.
Also below a few more minor / specific text comments:
- Some "see 3.3.3" mentions - no such section is defined. 3.5.3 ?
- Reference [draft-ietf-schc-arch] not defined. There's also a
[draft-ietf-schc-architecture]
- 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.
- 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.
- 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 (?)
- 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.)
- 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.
-> 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?
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.
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.
- 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!
- 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.
- 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.
- Sections 5 and 6: didn't look in detail here yet.
best regards,
Esko
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339_______________________________________________
6lo mailing list -- [email protected]
To unsubscribe send an email to [email protected]
