Re: [6lo] SCHC HC over IEEE 802.15.4: 2. Multihop route-over approaches
Hi Michael,
Many thanks for your feedback!
Please find below my inline responses:
On Thu, 13 Jul 2023 at 17:35, Michael Richardson
wrote:
>
> {I haven't read your draft, but I'll get to it}
>
>
Thanks!
> Carles Gomez Montenegro wrote:
> > - “Straightforward Route-Over” incurs the lowest header overhead, as
> it
> > only requires the SCHC Dispatch (1 byte). However, it is the most
> > demanding approach in terms of memory usage, since all network nodes
> > (including intermediate nodes) need to store all the Rules in use in
>
> At this point all constrained networks are purpose-built, usually for a
> single application. (This is not how many thought it would work, if you go
> back to 2007ish...)
> As I understand SCHC, the Rules are not dynamic, and so a network built
> using
> this method would be provisioned correctly.
>
>
The original assumption behind SCHC was that it is possible to know a
priori which will be the values of many of the packet header fields.
Therefore, as you say, the Rules would really be static.
However, perhaps more dynamic approaches could be enabled as well. But in
any case, for sure, and as the most simple case, a purely static approach
can be considered.
> > - “Tunneled, RPL-based Route-Over” incurs greater header overhead
> (with
> > some cases in the order of 12-16 bytes, although it may be more
>
> I'm guessing that this overhead is in the RH3, and that in the absense of
> SCHC, that we'd still have to spend that overhead?
>
As Pascal already replied, it would be IP-in-IP, RPI, SRH, and using RFC
8138 formats for efficiency.
>
> > - “Pointer-based Route-Over approach” also only requires the
> endpoints
> > to store the Rules they will need to communicate with other
>
> This feels like some kind of new optimized source routing mechanism?
>
>
It is actually a way to allow an intermediate node to quickly know which is
the IPv6 destination address in a received packet with a SCHC-compressed
header, without a need to store particular Rules for the communication
between the two involved endpoints.
> > A question that has been raised is whether we might want to keep all
> > three route-over approaches in the document or reduce the number of
> > such approaches. As authors we are in favor of enabling all of them,
> > since they may be complementary, and the most suitable one can be
> > chosen for each deployment.
>
> I don't object to multiple methods in theory, if there is a way to clearly
> articulate (at build time), which one will be used. But it would be better
> for mindshare and debugging, and code maintenance to have fewer methods.
>
>
I understand, and agree. Perhaps the methods are quite complementary. We
may need to clarify as well as possible the pros and cons of each one.
Once again, many thanks for your feedback!
Cheers,
Carles
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] SCHC HC over IEEE 802.15.4: 2. Multihop route-over approaches
Hello Michael
Case 2 RPL is hopefully RFC 8138. Else it’s the non storing tunnel as in RFC
9008, the SCHC always encapsulating to the root and back.
Regards,
Pascal
> Le 13 juil. 2023 à 17:36, Michael Richardson a écrit :
>
>
> {I haven't read your draft, but I'll get to it}
>
> Carles Gomez Montenegro wrote:
>> - “Straightforward Route-Over” incurs the lowest header overhead, as it
>> only requires the SCHC Dispatch (1 byte). However, it is the most
>> demanding approach in terms of memory usage, since all network nodes
>> (including intermediate nodes) need to store all the Rules in use in
>
> At this point all constrained networks are purpose-built, usually for a
> single application. (This is not how many thought it would work, if you go
> back to 2007ish...)
> As I understand SCHC, the Rules are not dynamic, and so a network built using
> this method would be provisioned correctly.
>
>> - “Tunneled, RPL-based Route-Over” incurs greater header overhead (with
>> some cases in the order of 12-16 bytes, although it may be more
>
> I'm guessing that this overhead is in the RH3, and that in the absense of
> SCHC, that we'd still have to spend that overhead?
>
>> - “Pointer-based Route-Over approach” also only requires the endpoints
>> to store the Rules they will need to communicate with other
>
> This feels like some kind of new optimized source routing mechanism?
>
>> A question that has been raised is whether we might want to keep all
>> three route-over approaches in the document or reduce the number of
>> such approaches. As authors we are in favor of enabling all of them,
>> since they may be complementary, and the most suitable one can be
>> chosen for each deployment.
>
> I don't object to multiple methods in theory, if there is a way to clearly
> articulate (at build time), which one will be used. But it would be better
> for mindshare and debugging, and code maintenance to have fewer methods.
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] SCHC HC over IEEE 802.15.4: 2. Multihop route-over approaches
{I haven't read your draft, but I'll get to it}
Carles Gomez Montenegro wrote:
> - “Straightforward Route-Over” incurs the lowest header overhead, as it
> only requires the SCHC Dispatch (1 byte). However, it is the most
> demanding approach in terms of memory usage, since all network nodes
> (including intermediate nodes) need to store all the Rules in use in
At this point all constrained networks are purpose-built, usually for a
single application. (This is not how many thought it would work, if you go
back to 2007ish...)
As I understand SCHC, the Rules are not dynamic, and so a network built using
this method would be provisioned correctly.
> - “Tunneled, RPL-based Route-Over” incurs greater header overhead (with
> some cases in the order of 12-16 bytes, although it may be more
I'm guessing that this overhead is in the RH3, and that in the absense of
SCHC, that we'd still have to spend that overhead?
> - “Pointer-based Route-Over approach” also only requires the endpoints
> to store the Rules they will need to communicate with other
This feels like some kind of new optimized source routing mechanism?
> A question that has been raised is whether we might want to keep all
> three route-over approaches in the document or reduce the number of
> such approaches. As authors we are in favor of enabling all of them,
> since they may be complementary, and the most suitable one can be
> chosen for each deployment.
I don't object to multiple methods in theory, if there is a way to clearly
articulate (at build time), which one will be used. But it would be better
for mindshare and debugging, and code maintenance to have fewer methods.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
[6lo] SCHC HC over IEEE 802.15.4: 2. Multihop route-over approaches
Dear 6lo WG, As you may have noticed, there are currently 3 approaches to enable route-over multihop in draft-ietf-6lo-schc-15dot4. A preliminary analysis of pros and cons of each one is provided in Appendix B of the draft, in -02 [1]. Summarizing: - “Straightforward Route-Over” incurs the lowest header overhead, as it only requires the SCHC Dispatch (1 byte). However, it is the most demanding approach in terms of memory usage, since all network nodes (including intermediate nodes) need to store all the Rules in use in the network. Therefore, it will be suitable for rather static, small networks and/or where nodes have sufficient memory. - “Tunneled, RPL-based Route-Over” incurs greater header overhead (with some cases in the order of 12-16 bytes, although it may be more depending on e.g. the number of hops), but only the endpoints need to store Rules, and only those Rules used for the end-to-end communications such endpoints are involved in. It requires the use of RPL, in its non-storing mode. - “Pointer-based Route-Over approach” also only requires the endpoints to store the Rules they will need to communicate with other endpoints. The header overhead contains a fixed 3-byte part and a variable one. The latter depends on the kind of interactions between endpoints: a) in special cases, it could be even zero, b) in intranetwork communication it could be 2-8 bytes (depending on how IPv6 addresses are built) and c) if interactions with various possible external networks it could be up to 16 bytes. This approach does not require the use of RPL, and is also compatible with RPL storing mode. There may be further subtleties to consider. A question that has been raised is whether we might want to keep all three route-over approaches in the document or reduce the number of such approaches. As authors we are in favor of enabling all of them, since they may be complementary, and the most suitable one can be chosen for each deployment. Thoughts? Would you have any preference? Thanks, Carles and Ana (document authors) [1] https://datatracker.ietf.org/doc/html/draft-ietf-6lo-schc-15dot4-02#name-analysis-of-route-over-mult ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
