Interim SCHC #10 2024

WG info

Meeting Information

Agenda

[16:00] Administrivia [10min]

[16:10] SCHC architecture concepts [30 min]

[16:40] AOB [ QS ]

Minutes

[16:00] Administrivia [10min]

PT doing introductions.

PT: At IETF 120, SCHC has 2 hours on Monday July 22nd, at a convenient
time for Europeans to attend.

AP: A call for WG adoption soon ends for SCHC for ZE devices. Good
feedback so far. Open point if we want to keep it with the same name or
not. I'd prefer to consider renaming later on if more use cases are
actually included. Is it feasible to do?
PT: No direct experience, but it should be doable. Better to adopt
first, and consider renaming later if need be. Also no final decision on
the document intended status (e.g., Informational or Experimental).
ER: Sounds good.
CG (on chat): Same here: no actual experience on something similar.
LT (on chat): I think it is better to keep tha name and make it evolve
if necessary.

PT: draft-ietf-schc-protocol-numbers is now available as a SCHC WG
document.

AM: Do we plan to cover all the drafts at IETF 120?
PT: We will have two hours, so we can cover everything that people
want/request to discuss.

[16:10] SCHC architecture concepts [30 min]

Presented slides:
https://datatracker.ietf.org/meeting/interim-2024-schc-10/materials/slides-interim-2024-schc-10-sessa-schc-architecture-for-6lo-01.pdf

CG presenting

CG (p2): Recapping on motivations for using SCHC for 802.15.4.
PT: You mentioned that the "Straightforward" mode can be complicated.
However, in a homogeneous network, devices are similar with one another,
then the only variable field is the IP address of each device.
PT: In case of WI-SUN they used DHCP to make sure they have addresses on
only 2 Bytes. In this case, with SCHC, you can have an address, which
contains the 2 significant bytes. So we shouldn't be too hard on the
"Straightforward" mode.
PT: On the "Tunnel-based" mode, networks like RPL-based can find it very
useful, although we have to provide some considerations.
PT: We need to discuss the security aspects of the "Pointer-based" mode.
It can be risky.
LT: If you can change a pointer, you can also change an address. The
attack is fundamentally the same.
PT: Agree, if you can change something you can change anything. It's
still worth discussing in the security considerations.

CG (p3-5): Examples of single-instance network. Here it's possible to
have the SCHC header always, fully compressed. RuleIDs must be unique
network-wide.
PT: The terms "Host" and "6LR" can be confusing, especially when using
the "Tunnel-based" mode.
PT: The Host sending the packet in tunnel mode is also an 6LR. It's a
leaf, but a routing-aware leaf, so it participates in the routing.
PT: There is another possibility, in which the Host is a RPL-unaware
leaf. In this case, the 6LR may need some minimal SCHC information, so
that it determines where to tunnel the packet.
CG: The document is distinguishing the two cases, but we need more
examples and clarifications.

AP: What do you have on the wire?
CG: The SCHC header, and then the Rule ID that corresponds to the SCHC
packet, not the SCHC header.
AP: What to you have after the Rule ID?
CG: The SCHC compressed packet.
AP: So the residue, anything resulting from the compression that used
the rule indicated by the Rule ID. "SCHC" header might lead to
ambiguities to clarify.
AP: How does a 6LR know how to take the right routing decisions?
CG: After decompressing, the needed information to see is visible.

AP: the way you use the RuleID makes me think of MPLS Labels. How does
it work for the BR?
CG: it decompresses the packet and routes as a function of the
destination IPv6 address.

PT: An RPL-aware leaf has to operate as per PRO for delivering packets.

AP: Maybe we can build a relation between Rule ID and Node identifier.
CG: Have to think about it.
LT: I don't see the benefit. The Rule ID is one thing, then maybe the
address or node identifier is in the residue that needs to be
decompressed first.
AP: Or in the residue you have only additional but not necessary
information. It might depend on the topology.

CG (p6-10): Examples of multiple-instance network. Exceptions apart, it
won't be possible to have the SCHC header fully compressed. In case of
collisions in the value of the Rule ID, the MAC address of the source
from the Mesh-Under header can still work as descriminator. But that
prevents a full compression of the SCHC header.

LT: This looks very generic and to specify in the SCHC part, not
necessarily specific of 802.15.4.
CG: Agree, it's more general. Maybe it's more for the architecture.
LT: Still good that you think of it here.

CG (p11-14): Recap of how the 802.15.4 frame format changes with the
SCHC header included.
CG (p15-16): We plan to add more text to put this better in the context
of the intended SCHC architecture.

AM presenting

AM (p17): Recapping the plan for the transition protocol stack as part
of the work on the SCHC architecture.
AM (p18): There is only one stratum for UDP and CoAP. Do we need to have
two separate SCHC headers (one for UDP and one for CoAP) even if we have
one stratum only?
PT: One should be enough, the idea behind the concept of stratum was to
have exactly one SCHC header per stratum.
LT: You need only one SCHC header that replaces the IP number. If you
had two separate strata for CoAP and UDP, then you need two SCHC
headers.
AM: What if there are two strata in the same endpoint? Why would you
need to?
LT: You might perform the two compressions at two different "places",
like the stack or the application.
PT: It depends if you talk about a logical/application endpoing or a
host. That's why we tried to disambiguate through the concept of
stratum. The SCHC header is basically the header for the stratum in
question.
AP: This feels a bit like a moving target. We kind of understand each
other, but it's better to first stabilize this in the architecture
document. Let's try to have -03 before the cut-off.

AM: The Session ID is linked to the instance.
AP: We are out of time for today; we'll continue this next time.

(in the chat)
Laurent Toutain16:47
I like a common set of rules, but we have to be careful with up and down
entries since the routing may change and a up may become a down

Alexander Pelov16:48
yes - if we have a nice definition which keeps the up- and down- that
would be a very nice property

Alexander Pelov16:49
maybe in RPL that would be Child->Parent is Up, Parent->Child is down

Laurent Toutain16:49
no the dodag may change

Alexander Pelov16:49
not while a packet is in transmission, right?

Laurent Toutain16:50
but an intermediary node will not know if it is up or down at looking at
the rule

Alexander Pelov16:51
you do it hop-by-hop ?

[17:04] AOB [ QS ]