Skip to main content

Minutes interim-2022-lpwan-11: Tue 16:00
minutes-interim-2022-lpwan-11-202210181600-00

Meeting Minutes IPv6 over Low Power Wide-Area Networks (lpwan) WG
Date and time 2022-10-18 14:00
Title Minutes interim-2022-lpwan-11: Tue 16:00
State Active
Other versions markdown
Last updated 2022-10-19

minutes-interim-2022-lpwan-11-202210181600-00

Interim #11 2022

Data / Time

Meeting Information

Interim Agenda

## [16:05] Administrivia                                         [15min] 
* Note-Well, Scribes, Agenda Bashing
* WG Status

## [16:15] Open Discussion                                       [40min] 
* Need for rule ID, device ID, and rule instantiation

## [16:55] AOB                                                   [ QS ] 

Past To Dos

Alexander to ping (again) compound ack authors for IPR

To Do Next

Interim Minutes

[16:05] Administrivia
[15min]

  • Note-Well, Scribes, Agenda Bashing
  • WG Status

Alexander does the introductory speech
Note well and stuff
Approval of minutes from last interim (no objection)

PT: Laurent will lead the this dicussion, some questions need to be
addressed, what is a Set of Rules ?, which device IDs will we have or
actually need to have

AP: For compound ACK I have all the answers from the authors for IPR BUT
LT.

SA: One note, there is one sentence that does not fill the length, LT
what is the fix for this?

LT: Yes, I know how to do it.

AP: We also have the length of the YANG model, we need to fix it.

PT: Yes we need to fix it, but don't worry about the length.

AP: Question on Compound ACK, Whas is reviwed by a YANG doctor, ans: No

PT: Could you look on it, I mean the little peace on YANG for Compound
ACK?

PT: I got positive notes for SigFox but only from the authors.

Eric: It does make sense.

PT: LoRa got more interest

PT: No opposition so it should pass.

PT: Please send your requests for slots during the meeting, there is an
slide template, we need to have it by Nov 4th.

PT: About the advancment, congrats to the authors ! we are just waiting
for the editors.

PT: Same for NB-IoT

Eric: The liaison statement is done

PT: Now go for the LT slides

[16:23] Open Discussion on Identifiers
[40min]

  • Need for rule ID, device ID, and rule instantiation

LT: I'm presenting just some ideas, not solutions

LT: Core needs to identify the devices to identify which rules will be
applied

LT: How to identify this internally?

LT: When there is an IPv6 packet arriving, how do we identify the
device?, In OpenSCHC, we look at the traffic, match it with a Rule and
get the ID of the device, which is also used to identify a Set of Rules.

In this case a RuleID corresponds to the Device ID, in the LoRaWAN Case
it is the DevEUI and if we have a UDP Tunnel the RueID is the "IPv4
Address + : + UDP Port"

PT: Does the Rule contains the MAC address of the device?, is this
related to the implementation, in my opinion it should not be like that.

LT: That's not the case, it is not inside the rule but used to identify
a Set Of Rules.

LT: We have a problem for example with NoCompression Rules cause we do
not know how to identify the Device ID in that case.

PT: Why is there a problem?, if you have two tables to match IP address,
MAC Address and Rules?

LT: We need this information to identify the destination of the traffic
when we get traffic from internet with IPv6 headers.

LT: What happends when the IPv6 Address changes?, we don't know how to
identify that.

PT: Do we need a device ID to index the table to identify devices

LT: A device can be a rounter also, so we migth have devices behind,
what will happen then?

PT: we can do it differently with a .. mappiing, we can never have a
Rule matching all the devices.

AP: Maybe sending the packet to the next hop, to see if there is a Rule
on that point matching the packet

PT: The case of RPL does exactly that, but the device ID should be in
the packet

AP: you said that the IPv6 is an identifier but in OpenSCHC, you can
have the same IP but different ports.

LT: Yes, it can be done like that, that's why it is not simple to handle
several devices

AP: Maybe having a table with duplicated values so that different rules
can be applied for different devices?

PT: yes that's a way of doing it, but I don't like that; I have a patent
to use SCHC to route

LT: Another case is the mesh topology, we need to identify the rule by
having two elements (core-device), but that cannot be applied like that
here, so one way to do it is to have in the Rule ID the two identifiers
(Ivan's draft).

PT: It does not matter who's the core of who

CG: I have similar questions as LT, the end points need to know in
advance its roles, like Core or Device, and the Rules should be written
acordingly.

PT: That is true if you want to do it flat

LT: I disagree, we need to know the role.

PT: we need to have a session on this

CG: In some cases we know who will start the exchange, but that's not
always the case, and the Rules needs to be written in advance.

PT: yes, the rules yes but that's not the case for IPs

PT: We should have a single set of rules for all the network

AP: We already have this discussion, we need to have a session specific
on that cause we can get lost, let's have a side meeting in London

LT: Other topic, provisioning rules on devices, we need to consider
security aspects, for instance in the YANG model we have restrictions
like saying that devices cannot change Identifiers for example. We can
extend this at the control using the YANG data model.

AP: That's my second point, maybe ask this to YANG doctors, to get some
feedbak from previous cases.

LT: For me saying that the same set of rules for all the network it's an
optimization.

AP: What about authentication?, who has the rigths?, is it a constant or
can anyone change the fields?

PT: Having a single set of rules is a way of securying it since with
crypto we can secure it by using signatures.

LT: the beauty of CBOR is that it doesn't have lots of spaces.. you can
easily add hash signs and others

PT: Do we sign the non-mutable fields too?

LT: That's another story, but with YANG we can handle permissions.

PT: We can sign some fields in the same way it's done in IPSec

PT: We need to look for a room for the side meeting

PT: Meeting adjourned

[16:55] AOB
[ QS ]