(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. (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... 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...). Any thoughts or preferences from the 6lo and SCHC WGs? > > 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". Cheers, Carles (as WG participant) > > > Thanks > > Kiran > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > <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>
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
