Hello Carles Many thanks! Will you present your draft at the IETF 114 LPWAN meeting this time ? - I just posted a call for agenda item. Anyway we'll chat at the WG meeting during the slot on architecture. Also, for mesh under, the connection can the pair of MACs (=> only one Instance per pair), but there is no implicit sense of direction. So it's not per se a solution. I'll need to understand better how you want to install / use that " single Rule (also written beforehand) ".
Take care, Pascal > -----Original Message----- > From: Carles Gomez Montenegro <[email protected]> > Sent: jeudi 7 juillet 2022 12:59 > To: Pascal Thubert (pthubert) <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: [6lo] [lp-wan] I-D Action: draft-ietf-lpwan-architecture-02.txt > > Hi Pascal, > > Many thanks again for the discussion and your detailed insights! > > Please find below my inline responses/comments: > > > 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. > > Great! > > > 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). > > This sounds promising! > > It would be nice to explore this approach. > > > * The hard case is to make SCHC really multihop. It is not designed > > for that. > > Agreed. This is a challenge, but hopefully we might be able to find/create > suitable techniques to support SCHC (or parts of SCHC) for multihop. > > > 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. > > Actually, the current approach in draft-gomez-6lo-schc-15dot4 is to use just > the header compression part of SCHC, and keep using 6LoWPAN/6lo > fragmentation. In fact, I think that SCHC fragmentation is partly inspired by > RFC 8931, so both fragmentation approaches share some of the main features > anyway. > > > 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. > > Agreed. Route-over multihop with SCHC-compressed headers would be suitable > "as is" rather for small networks (low number of nodes), or if node memory > constraints are not too severe, and if context is relatively stable. > > (Probably not suitable otherwise...) > > > 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. > > I see! > > Another area to consider is Mesh-Under, where I understand that there is no > particular challenge to use SCHC header compression for multihop > communication. > > >> - 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. > > Yes, I agree with your text, and I think that is actually my meaning... > > > Keep safe, sad we cannot continue this conversation in Philly since > > I'll be remote. > > Well, I'll be remote too. :-) > > Hopefully, we can find some way to progress online anyway... > > Many thanks, Pascal!! > > Carles > > > > > 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/lp-wan > > > > _______________________________________________ > > 6lo mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6lo > > > _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
