Minutes IETF115: lpwan: Fri 12:00
minutes-115-lpwan-202211111200-00

Meeting Minutes IPv6 over Low Power Wide-Area Networks (lpwan) WG
Date and time 2022-11-11 12:00
Title Minutes IETF115: lpwan: Fri 12:00
State Active
Other versions markdown
Last updated 2022-11-14

minutes-115-lpwan-202211111200-00

Meeting Information

WG info

Data / Time

Meeting Information

WG Meeting Agenda

### [12:00] Administrivia                            [15min]
* Presenter: Alexander Pelov
* Note-Well, Scribes, Agenda Bashing
* WG / drafts Status / NB-IOT
* Intro to the need for rechartering


### [12:15] Rechartering [15min]
* Presenter: Chairs
* Topics: Review proposed work items

### [12:30] SCHC Convergence Profile (new work) [10min]
* Associated draft: draft-aguilar-lpwan-schc-convergence
* Presenter: Sergio Aguilar
* Topics: Present new work.

### [12:40] Need for IDs - Impact on Architecture [45min]
* Associated draft: draft-ietf-lpwan-architecture
* Presenter: Chairs, Laurent Toutain
* Topics: Open Mike on need for IDs and their management

### [13:25] AOB [QS]

WG Meeting Minutes

[12:00] Administrivia
[15min]

  • Presenter: Alexander Pelov
  • Note-Well, Scribes, Agenda Bashing
  • WG / drafts Status / NB-IOT
  • Intro to the need for rechartering

Ivan and Sergio are taking the minutes
Agenda presentation
New item in the agenda: Dominique about the Hackathon.

AP : The schc over sigfox and compound ACK we are almost there.
For Compound ACK, We're waiting for lastest version

SA: Compound ACK, It is ready, and I think it is already on the data
tracker

Ana: Waiting the end of the last call, She can press the button
Chairs: push the button.

Chairs: YANG data model is in the editor queue, thanks for the authors

Chairs: NB IoT, it is really advanced, the liaiseon is

Pascal: I've never seen a document going smoothy to the ISG

Eric: during the 3GPP-IETF coordination on Tuesday, it was well
received, for the work to be done at 3GPP, companies have to send a
SID/WID to 3GPP

Eric: wait to the end of November to see how to do the informative parts
and the normative part as 3GPP meets next week and a 3GPP review will be
done.

AP: Is there any interest to continue on OAM?

DB: I'm interested to continue this work!

PT: Regarding the architecture, and how SCHC works over any type of
connectivity. Session is accepted in the model. This session is implicit
for LPWAN. In on a more diverse type of networks, there is a need for
revisiting the definition of session since it is not implicit.

Bob: I did a comment about this draft the security secction is
incomplete, indication when security is below transport.
It should be added to the architecture.

PT: When it is over LPWAN was considered, over foo it is not.

[12:15] Rechartering
[15min]

  • Presenter: Chairs
  • Topics: Review proposed work items

PT: Documents are moving forward, and it is time to recharter, do not
hesitate to come to the mic and say what subjects are you interested on.
Discover a lot of new foos. SCHC (compression) over 15.4 in 6lo. PPP in
interea, probably better here.

Any interest in SCHC over foo

JCZ: Depending the scope beyong LPWAN. Does the rechartering wants to
change the group name.

Eric: it is logical, but in the past another group wanted to do the same
but it was not possible beacause of the datatracker. I will check again.

PT: New message for handling message lost. Send more bits than needed in
case are lost.

Bob: not instead but in addition.
Pascal: Rename to HARQ

PT: SCHC Header,
In interea ether type

Bob: IP protocol number, Ether type, and UDP port number are in intarea
and will progress

PT: we may need SCHC as an extention header.

LT: To have a protocol number, it is good because it can work on IPv4
and IPv6

Bob: Adding SCHC in an extension header, raise a lot of negative
comments in intearea, they're very much for protocol number.

Eric: we can discuss here but it is an inearea draft

PT: Let's discuss in the mailing list

Bob: we need uses cases to support it (UPD port and ether type)

PT: this is not an intera work, we need to figure out whay would be
carried, thats why we need the rechartering

Bob: we don't need session id because it's implicit

PT: SCHC Instance between devices.

PT: Session Setup: since we're moving from LPWAN to other topologies, we
need to figure out how to download the same set of rules and instantiate
for example the IP address.

AP: We have goten those question many times in the past, the answer was
that we'll solve in the future, I think we have now the knowlege to
answer. CORECONF over SCHC.

LT: Security is very important, here we have different bullets to be
really explicit in the architecture

PT: we need to update the security section of the architecture.

Bob: With regard to the negotiation of the rules, there is a draft in
IKE on how to negociate rules. IMHO We should do in in a P2P way, not
client and server.

AP: Both peers can have the server and client

PT: Any comment on more items, we need to have the feedback before
starting to write the rechartering.

LT: For the YANG model, it is not only about optimization but also
extention

[12:37] SCHC Convergence Profile (new work)
[10min]

SA: update of the draft, it started as an individual submission.

LT: thanks for the initiative, I like the fact of having more open
implementations, but for a very very constrainded end devices, we migth
wont to have the devices not having to handle directly the rules. So,
for example we can have an implemntation with very little code.

PT: The two foo that you have might not survive in the long term, that
might be the strong part of your proposeal, are you planning to have
something more generic for other Foos

SA: There have to be an adaptation for different traffic profiles, for
instance there is a part on the draft addressing downlink

Bob: other techs with more traffic, that might be a good example and
that's exactly what I'm working on.
Bob: as examples of foos, 802.16, 802.11.ah with high traffic.
Compression helps reducing collisions.

AP: At the beginning of the group we have the idea of having a minimal
rule (of convergence profile if you will) for different technologies.
I'm not sure how's is going to be working, if I underenstant well, both
are different to what you propose, so it'll be complicated to add this
new profile.

LT: do you plan to consider mobility in this scenario

SA: since we can send on different nets yes,

LT: is more related to the IDs

SA: We're proposing a single ID for all thechnologies, that can help us
with the convergence and with a device moving from one technology to
another for instance.

AP: We need to look at your draft regarding the session stablishment for
this convergence profile.

[12:50] Hackaton
[45min]

  • Presenter: Dominique Barthel
  • Topics: Feedback of the

DB: Ivan an Laurent work on cleaning the OpenSCHC repo, micropython
implementation, sergio working on the interconection to the new sigfox
network server to openSCHC, Ivan and Laurent also work with Martine
Landers to set up a connector with LibSCHC for ICMP traffic.

AP: Amazing work in this 5 years of Hackathon.

[12:59] Need for IDs - Impact on Architecture
[45min]

LT: I'll also sumarize what was said on the side meeting yesterday
LT: We have to merge all the inputs we get from the reviwers of the YANG
DM in the architecture draft.
LT: We would also like to extend this work to OAM and Compound ACK.
CORECONF a compact way of the YANG model.

LT: How to protect elements of the rules to avoid devices to change
fields if it does not have the rigths.

LT: currently you have protection to access specifics field. Each field
will have a specfic id in yang, or number in CORECONF. Same column, same
id, same number. A colunm is write only or read and write.

LT: In SCHC we will like to have something more precise, we can imagine
an attack where a device is compormised and change the address to
another device.
LT: Improve or augment the security we have in YANG DM.
Device can only manipulate its own information, not of other devices in
the core. Device only send messages for its own representation.

AP: That was a very interesting discovery, we want to have the same
level of securty as if the device had the full IPv6, we can imagine also
a case where a device can push malicious rules to the system. Thats
something we do not want to allow.

PT: We start disussing it on the side meeting, my view is that you need
to identify first the session and then match the rules, NOT the other
way, if not there is no way to filter traffic. The problem is when the
packet arrives from the internet, not in the compressed form.

LT: we dont want to add any new feature but to be used as in the
internet, we also need to define the way this reconfiguration of devices
is done, maybe CORECONF for constrainded end devices?, maybe another
level of encryption?.

LT: Now, for the mesh topology: nodes that talk to othe hosts useing
SCHC. You can have several cores, you can say A is a device and B core,
there is a problem with C, because it can be core or dev.
According to Ivan draft, you cannot have the same rule for both
direcctions. It is static, depends on the information of the rules, if
dinamic, a new protocol will be required to identify dev or app.
we need to look to solutions in the arquitecture document.

PT: SCHC instance (is a session between dev and app), number of cases
where the session identification is implicit, no session negotiation,
nor identification. LoRaWAN you can have the device id. Bluetooth, the
server can be app.
When we start a PPP connection, the device start the communication.

There cases like mesh, it can be implicit or not. Need of a secure
negotiation protocol

AP: Thank you everyone, see you at the next IETF and the interm meeting.

PT: Meeting adjourned

[13:25] AOB
[QS]