Re: [6lo] SCHC HC over IEEE 802.15.4: 2. Multihop route-over approaches

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]> a écrit :
> 
> 
> {I haven't read your draft, but I'll get to it}
> 
> Carles Gomez Montenegro <[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo