Re: [lp-wan] [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.ietf@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>