Hello Carles > -----Original Message----- > > Many thanks for updating the LPWAN architecture draft as per our discussion! Yep; many thanks for your hints and comments, your steering in the right direction is really helpful.
> In my opinion, the draft now provides the basis to generalize the use of the > SCHC roles (Dev and App) or directions (Downlink and Uplink) for any > networking environment or topology. Cool > (And other drafts, such as draft-gomez-6lo-schc-15dot4, can now refer to the > LPWAN architecture draft to this end.) > > I have two further comments: > > - In section 5.1, when talking about the P2P SCHC Instance, an assumption > seems to be that there is one link between the two peers. However, there > could be several links (understood as radio hops) between the peers. For the > sake of generality, perhaps the draft could also explicitly mention that > there can be a link **or a path** between the two peers, perhaps also > explicitly referring to 'mesh' or 'multihop' networks, which are now covered > by the draft as well. We started that discussion but we're not there yet so I cannot turn the result in words. I'd say that there is the easy case and the hard case. * The easy case is RPL non-storing. RPL imposes a tunnel between the Root and the device and that can serve as a P2P transport. So we can do RFC 8138 (really efficient) for the outer tunnel and then SCHC inside. For this, we are almost all set, draft-gomez-6lo-schc-15dot4 could express the details on how we find that it is SCHC inside as opposed to RFC 6282 - willing to help here. Using the non-storing mode overlay, we're back to the hub and spoke and the Root is naturally Uplink. Note that if the destination is "external", which would probably be the case of a LFN (that's what Wi-SUN does), then RFC 9008 is clear that the Non-Storing mode signaling and tunneling applies as well, all set there too. And nothing prevents also using the tunnel in storing mode when there's SCHC inside, it's partially there anyway (e.g., for the root to add the RPI). * The hard case is to make SCHC really multihop. It is not designed for that. E.g., fragmentation, either you reassemble at each hop and lose a lot of the benefit, or you need to consider extending SCHC for things like RFC 8931. Then there's the rules. If there are many and arbitrary destinations then it's hard for the parent to maintain a state for all the destinations of all the children and descendants. We're back to saying, let the root do that, but then, why not tunnel to it like in the case above? So we have to decide whether we model for the H&S overlay like RPL, or opt for a complicated change in SCHC. > > - The convention defined in 5.1 provides a default way to determine who is > Dev and who is App (or what is understood by Uplink and Downlink). > My interpretation is that: > > o If it is possible to know beforehand which one of the two peers is Dev > or App, a single Rule (also written beforehand) may suffice to offer > the best header compression performance for both communication > directions (e.g., as in RFC 8724). > > o In a less predictable scenario, where either one peer or the other > could be the first to transmit (e.g., if they are peers in a strict > sense), the convention still allows to determine the role of each > device, but two Rules (one for each direction) may need to be written > to achieve the best header compression performance for both > communication directions (one for each direction). > > Perhaps some comment about this (i.e., the amount of context may be > reduced if a scenario is predictable) could also be added to the draft. Works for me, that was the intention. I like your wording. I'd like to elaborate in what you mean by " a single Rule (also written beforehand) ". Right now we say that the a priori knowledge (rule) is fully extrinsic to SCHC and has to do with the device (supports only 1 Instance), the network (the Hub is Uplink) or the supporting connection or tunnel (the node that starts it is Downlink). You seem to make it a SCHC Rule. Is that your meaning? If so, this may affect the model. Keep safe, sad we cannot continue this conversation in Philly since I'll be remote. Pascal > > Cheers, > > Carles > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the IPv6 over Low Power Wide-Area > > Networks WG of the IETF. > > > > Title : LPWAN Static Context Header Compression (SCHC) > > Architecture > > Authors : Alexander Pelov > > Pascal Thubert > > Ana Minaburo > > Filename : draft-ietf-lpwan-architecture-02.txt > > Pages : 14 > > Date : 2022-06-30 > > > > Abstract: > > This document defines the LPWAN SCHC architecture. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-lpwan-architecture/ > > > > There is also an htmlized version available at: > > https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-architecture-02 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-architecture-02 > > > _______________________________________________ > lp-wan mailing list > lp-...@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
