Hi Kiran, Many thanks for your additional comments/responses.
Couple of questions, regarding the ‘radio and wireline' technologies that you envision: do those technologies support multihop topologies? Also, if you are considering specific technology examples, I am curious to know: which would such technologies be? Thanks in advance! Cheers, Carles (as WG participant) <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Libre de virus.www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Wed, 5 Apr 2023 at 01:44, Kiran Makhijani <kiran.i...@gmail.com> wrote: > Thanks Carles. Follow up comments inline below with [KM]. > > > > *From: *Carles Gomez Montenegro <carles.go...@upc.edu> > *Date: *Tuesday, April 4, 2023 at 9:51 AM > *To: *Kiran Makhijani <kiran.i...@gmail.com> > *Cc: *6lo@ietf.org <6lo@ietf.org>, s...@ietf.org <s...@ietf.org>, lp-wan < > lp-...@ietf.org> > *Subject: *Re: [6lo] Transmission of SCHC-compressed packets > (draft-ietf-6lo-schc-15dot4) > > (Resending, since there was a typo in one of the email addresses... > Apologies for that!) > > > > Carles > > > > ---------------- > > > > Hi Kiran, > > > > (Adding LPWAN/SCHC in CC' as well...) > > > > Many thanks for your message. > > > > Please find below my inline responses/comments: > > > > On Tue, 4 Apr 2023 at 07:20, Kiran Makhijani <kiran.i...@gmail.com> wrote: > > Hello, Carles, and other authors > > Thank you for presenting this work and presentation last Friday. I am > repeating here what we discussed in the hallway after the meeting. > > > > Great, thanks! > > > > I am wondering is it possible to generalize the spec for any layer 2 not > just 15dot4, since there will be more commonalities than differences as we > consider nuances over different types of media. I work in industrial IoT > which is a mix of radio and wireless IoT devices and I can see that SCHC > can be beneficial for both type of field devices (both are resource > constrained). What do you think? > > > > I think that it is indeed possible to use SCHC (or, at least, SCHC > components, such as the header compression part) over many different Layer > 2 (L2) technologies (including, but not limited to the LPWAN space for > which SCHC was originally designed). In order to enable that, I understand > that there are at least two options: i) producing one SCHC-over-foo > specification per L2 technology (which is the current approach in > draft-ietf-6lo-schc-15dot4); and ii) producing a generic specification plus > one L2 technology-specific document describing how to apply the generic > specification for a given target L2 technology. I understand that you would > be interested in this second option. > > > > [KM] Yes, I would like to see second option with a generic specification. > I also had typo above - wanted to say ‘radio and wireline IoT devices’. > > > > (Note: interestingly, 6LoWPAN was originally designed to efficiently > support IPv6 over IEEE 802.15.4, and then the 6Lo WG reused/adapted 6LoWPAN > to support IPv6 over several other L2 technologies, producing one > corresponding specification for each L2 technology; this is similar to the > first option mentioned above. However, the LPWAN WG work has followed the > second option above, since SCHC is generic and then its use over a > particular L2 technology is enabled by means of a technology-specific > document.) > > > > When we started to work in our current draft (draft-ietf-6lo-schc-15dot4), > we also considered the two options. At that moment, the first option seemed > to be more focused, and there was no explicit interest yet from other > technologies, so probably there was not enough motivation for a generic > specification. Perhaps, at this moment, the picture may be starting to > change... > > [KM] As I said, it is really useful to produce generic (or common spec). > So far, I did not see too many dependencies on 802.15.4. I think we should > go with generic approach. > > > > If there is enough interest, we might consider producing a generalized > version of draft-ietf-6lo-schc-15dot, and then there would need to be > another document specifying how to use the generalized functionality over > IEEE 802.15.4 or any other target L2 technology. However, we may also need > to consider the additional complexity of such a process (perhaps the 6Lo > and SCHC chairs and ADs may have some opinion in this regard...). > > [KM] sounds good. > > Any thoughts or preferences from the 6lo and SCHC WGs? > > [KM] I am ok whichever group it goes to – but yes, logically SCHC makes > sense as Pascal mentioned. > > > > > > If you accept that then, it will be possible to pick one approach. I felt > that right now 4 options are too many and a bit confusing. Perhaps, we can > evaluate them to produce requirements, then see if one solution can satisfy > those? To be honest I still have not finished reading the entire document > so must have misunderstood your presentation, but will be happy to help > improve it, however possible. > > > > I understand that you refer to the 4 options (currently, "approaches") for > multihop communication. Yes, we are still in relatively initial stages of > the draft, exploring different approaches and their pros/cons. I also think > that the number of approaches would need to be lower. > > > > In my opinion, we should define at least two "approaches": one for mesh > under, and at least one for route-over. Regarding the latter, initially > there was only the "Straightforward" approach, which offers the lowest > header overhead but requires all nodes to store all the Rules in use in the > network. For the sake of scalability, the "Tunneled, RPL-based" approach > was added, so that 6LRs do not have to store the Rules. However, we just > added in -01 the "Pointer-based" approach, which is also scalable, but with > lower header overhead. We are already considering modifications that can > address issues in the existing "approaches". Once things become a bit more > stable, we might simplify the specification, perhaps by removing or > combining one or more "approaches". > > > > [km] Yes, I like the suggestions on a procedure each for mesh under and > router-over. My sense was that pointer-based approach was quite inclusive > and scalable. > > Thanks, > > Kiran > > > > Cheers, > > > > Carles (as WG participant) > > > > > > Thanks > > Kiran > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > > > > [image: Image removed by sender.] > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> > > Libre de virus.www.avg.com > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> > > >
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
