Subject: Re: [lp-wan] lpwan-overview comments

From: Stephen Farrell <[email-masked]>
Date: Sat, 1 Jul 2017 19:07:42 +0100

Hiya,

On 28/06/17 09:05, Alper Yegin wrote:
> Hi Alex,
> 
> No, they’d not.
> Btw, the I-D is based on the LoRaWAN 1.0.2.
> And we are working towards publishing the LoRaWAN 1.1 in September.
> Depending on the pace of IETF processing this I-D, it may stay with LoRaWAN 1.0.2 details, or an update may fold in LoRaWAN 1.1 changes as well.
> 

Given the stated milestones I guess that we should stick with
describing 1.0.2 in the WG overview draft.

Cheers,
S.

PS: I'll respond to the other mail in a bit.

> Alper
> 
> 
> 
> 
> 
>> On Jun 28, 2017, at 10:56 AM, Alexander Pelov <[email-masked]> wrote:
>>
>> Thanks for the comments and the detailed review, Alper!
>>
>> I guess the changes you describe are not likely to be changed until the specs you describe get published, right?
>>
>> Thanks again,
>> Alexander
>>
>>
>>> Le 28 juin 2017 à 09:05, Alper Yegin <[email-masked] <mailto:[email-masked]>> a écrit :
>>>
>>> Dear LPWAN WG members and Stephen,
>>>
>>> I made one more pass over the LoRaWAN section of the I-D and spotted the following points:
>>>
>>>
>>>    A LoRaWAN network has a short network identifier ("NwkID") which is a
>>>    seven-bit value.  A private network (common for LoRaWAN) can use the
>>>    value zero.  
>>>
>>>    If a network wishes to support "foreign" end-devices
>>>    then the NwkID needs to be registered with the LoRA Alliance, in
>>>    which case the NwkID is the seven least significant bits of a
>>>    registered 24-bit NetID.  (Note however, that the methods for
>>>    "roaming" are defined in the upcoming LoRaWAN 1.1 specification.)
>>>
>>>    In order to operate nominally on a LoRaWAN network, a device needs a
>>>    32-bit device address, which is the catenation of the NwkID and a
>>>    25-bit device-specific network address that is assigned when the
>>>    device "joins" the network (see below for the join procedure) or that
>>>    is pre-provisioned into the device.
>>>
>>>
>>> In the LoRa Alliance we made a change to the way DevAddrs are generated based on the NetIDs. It’s no longer simply using the 7 least-significant-bits of NetID as the 7 most-significant-bits of the DevAddr. Even though the generation scheme was already described in the LoRaWAN 1.0 spec, the end-device always treated the DevAddr as a 32bit value, hence it did not matter how that value was generated as far as the end-device is concerned. The new scheme, which allows more efficient allocation and use of NetIDs, is described in the Backend Interfaces spec, which is not published yet.
>>>
>>> What that means is, in this I-D, we better not describe "NwkID=7 bits” detail. 
>>>
>>> So, I’d  propose to rewrite the above 3 paragraphs as follows (further text massage welcome!):
>>>
>>>
>>>    In order to operate nominally on a LoRaWAN network, a device needs a
>>>    32-bit device address, that is assigned when the
>>>    device "joins" the network (see below for the join procedure) or that
>>>    is pre-provisioned into the device.  In case of roaming devices, the device address
>>>    is assigned based on the 24-bit NetID that is allocated to the networks
>>>    by the LoRa Alliance. Non-roaming devices can be assigned device addresses
>>>    by the network without relying on a LoRa Alliance-assigned NetID.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>    End-devices are assumed to work with one or a quite limited number of
>>>    applications, identified by a 64-bit AppEUI, which is assumed to be a
>>>    registered IEEE EUI64 value.
>>>
>>>
>>>
>>> AppEUI is being renamed as JoinEUI in LoRaWAN 1.1, and in fact it identifies the JS.
>>> JoinEUI and JS terms are not present in LW1.0.x, but nevertheless the latest definition of the AppEUI in LW1.0.2 is as follows:
>>>
>>>
>>>
>>> The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies
>>>
>>> the entity able to process the JoinReq frame.
>>>
>>>  
>>> So, we better not treat it as application identifier, but as identifier of the entity that can authenticate the Join-request frames.
>>>
>>> For example, instead of:
>>>
>>> AppEUI	IEEE EUI64 naming the application
>>>
>>> We better say:
>>>
>>> AppEUI	IEEE EUI64 naming the entity that processes Join-request
>>>
>>>
>>>
>>>
>>> Thanks Stephen.
>>>
>>> Alper
>>> _______________________________________________
>>> lp-wan mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>
> 
> 
> 
> 
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 1 Jul 2017 19:15:33 +0100

Hiya,

>    by the network without relying on a LoRa Alliance-assigned NetID.

I made that change.

> AppEUI	IEEE EUI64 naming the entity that processes Join-request

So I just don't understand how that can be correct, sorry;-)

A join-request is processed by a NS (or, in 1.1 a JS). There are very
few of those, maybe 1 per n/w. There are many more device-types, which
do mostly map 1:1 with AppEUIs. And the same device-types can be found
in many networks.

So the suggested text just seems incorrect to me.

I'd say we're better to just stick with 1.0.2 terms tbh.

Cheers,
S.

---

From: Alper Yegin <[email-masked]>
Date: Sat, 1 Jul 2017 22:18:35 +0300

Hi Stephen,

> I'd say we're better to just stick with 1.0.2 terms tbh.

If we want to strictly  stick with the LW1.0.2 definition, than it’d be:

AppEUI	IEEE EUI64 application id that identifies the entity processesing Join-request

In practice, it identifies the JS.

Note that:
- NS and JS may be co-located or separated. This is true for both LW1.0.x and LW1.1 specs.
- The entity that processes the Join-request and generates Join-accept is the JS.
- Single NS may be connected to multiple JSs.
- Spec is based on 1:1 relationship between the end-device and JS. (Obviously, implementations can extend that).
- If the NS knows the identify of the JS to process an incoming Join-request based on the DevEUI, then AppEUI (which is later renamed to JoinEUI in LW1.1) has no significance. Otherwise, the NS relies on the AppEUI (JoinEUI) to identify the JS to process the request.

I just elaborated on these details, not to suggest including in the draft, but to point out that the significance of the AppEUI is to “ identify(ies) the entity able to process the JoinReq frame.” as stated in the LW1.0.2 spec. As long as we capture that, it is OK if the draft also refers to it as “application id”. (The reason name of the Join-request field morphed from AppEUI into JoniEUI in LW1.1 is basically this.)

Regards,

Alper

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 1 Jul 2017 20:40:56 +0100

Hiya,

I suspect this is one of those where we'll only understand
one another f2f, but...

> AppEUI	IEEE EUI64 application id that identifies the entity processesing Join-request

Just to note: the above doesn't help me. I read it as the same as
your previous suggested text, and hence, for me, it just reads like
a false statement. (I don't mean badly worded, I mean untrue:-)

> In practice, it identifies the JS.

Let me try explain why I don't get that.

Each instance of some class of device will have the same AppEUI,
call that "X." Let's say there are 10^5 instances of devices
like that.

Let's say there are 2 LoRaWAN networks, each with an NS that has
a co-located NS. With half the "X" type devices in each.

Both networks (call them N1, N2) have devices of the type that
uses AppEUI X.

There is a 5000:1 ratio between instances of X and NS's/JS's
in each network.

X therefore does not identify an NS or JS or anything like that.

Do you see why I'm confused if you want to say that X identifies
or names the JS?

Cheers,
S.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Jul 2017 11:39:12 +0000

We are definitely not communicating, Gengyu.

If you elide the ruleID at the beginning of a fragment and start with the dtag, then the parser will interpret the dtag as a ruleID.

Maybe you are not considering that a non-fragmented packet maybe interleaved between fragments? 

Pascal

-----Original Message-----
From: weigengyu [mailto:[email-masked]] 
Sent: mardi 27 juin 2017 05:12
To: Pascal Thubert (pthubert) <[email-masked]>; Carles Gomez Montenegro <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [lp-wan] Fw: re-order header field request

Hi Pascal,

> We need the Rule to say fragment on each fragment,
All framents of a IPv6 packet obey one rule, the Rule ID is included in the first fragment is enough for conveying this information.

> and then the dtag.
All framents of the packet contain the same Dtag as defined.

> Starting the next fragment with the dtag would confuse the parser 
> which would interpret the dtag as another rule.
Put the Dtag at the front.
Defining the first two bits of Dtag as an indication of the first fragment, fragments of the minddle and  the last fragment.

00 the first fragment
10 fragments of the minddle
11 the last fragment

If the first two bits are '00', the Rule ID is followed.
If the first two bits are not '00', the fragment does not contain the Rule ID.
If the first two bits are 11, it is the last fragment.

I believe that it is worth to have this two bit to suppress the space of Rule ID in the successive fragments.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Pascal Thubert (pthubert)
Sent: Monday, June 26, 2017 4:33 PM
To: weigengyu ; Carles Gomez Montenegro
Cc: [email-masked] ; [email-masked]
Subject: Re: [lp-wan] Fw: re-order header field request

Hello Gengyu

We need the Rule to say fragment on each fragment, and then the dtag. 
Starting the next fragment with the dtag would confuse the parser which would interpret the dtag as another rule.

Cheers,

Pascal
-----Original Message-----
From: lp-wan [mailto:[email-masked]] On Behalf Of weigengyu
Sent: vendredi 23 juin 2017 16:26
To: Carles Gomez Montenegro <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [lp-wan] Fw: re-order header field request

Hi,

> I think there are problems with this proposal. If the Rule ID of 
> successive fragments is suppressed, how does a receiver know whether 
> those successive data units are actual fragments or not, or how the 
> data unit has to be processed?

The Dtag can be used for knowing "whether those successive data units are actual fragments or not, or how the data unit has to be processed. "

For example, if an IPv6 packet is partitioned into two fragments, the first fragment inclues a Rule ID and a Dtag, the second fragment includes the Dtag without the Rule ID.

After the first fragment is sent, the Rule ID is binded with a Dtag for this packet.
The receiver can know which the Rule ID is used by the Dtag.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Carles Gomez Montenegro
Sent: Friday, June 23, 2017 6:47 PM
To: weigengyu
Cc: [email-masked] ; [email-masked]
Subject: Re: [lp-wan] Fw: re-order header field request

Hi,

> Hi Arun and all,
>
> After reading through the draft-ietf-lpwan-ipv6-static-context-hc-04,
> one point needs to be exiplicit described: how many Rule IDs are used to
> fragment one large IPv6 packet?

What we currently have in the document is:

   "The Rule ID in a fragment is set to a value that indicates that the data
   unit being carried is a fragment."

So currently we do not explicitly indicate how many Rule IDs are needed
for fragments of a large IPv6 packet. The most efficient solution is to
just use one Rule ID to signal "this is a fragment". However, it is
probably safe to keep this open in the SCHC document, so that future
technology-specific SCHC over foo documents have freedom to specify
whatever better suits their needs.

> By my understanding, whne one IPv6 packet is fragmented, it adopts only
> one Rule ID.
> Each fragment contains the same rule ID and Dtag.
> Anything wrong?

DTag (if present) has to be the same in all fragments carrying the same
IPv6 packet.

One Rule ID to signal 'this is a fragment' is fine.

> Such a way to deliver the repeated Rule ID can be suppressed.
> It may be available to have the first fragement only include the Rule ID
> while containing the Dtag.
> And the following successive fragments have the Dtage without the Rule ID.
> The receiver can get the correct Rule ID from the first fragment referred
> as the same Dtag.
>
> The Rule ID is suppressed in fragments from the second to the last.

I think there are problems with this proposal. If the Rule ID of
successive fragments is suppressed, how does a receiver know whether those
successive data units are actual fragments or not, or how the data unit
has to be processed?

Thanks,

Carles

---

From: Alper Yegin <[email-masked]>
Date: Mon, 10 Jul 2017 16:50:25 +0300

Hi Stephen,

> one another f2f, but…

One more try over email. If still not clear, we can chat over the phone. I won’t be at IETF this time unfortunately.

When confronted by a Join-request, the NS needs to figure out how to authenticate the request.
If the NS can recognize the DevEUI, then it’d know how to do the auth (e.g., by locally, or by forwarding to an external JS for that given DevEUI entry).
If the NS cannot recognize the DevEUI, then it resorts to AppEUI (or JoinEUI, both are different names for the exact same field in the Join-Request — name change happening in revisions). AppEUI/JoinEUI tells the NS who can authenticate that request (a local/co-located JS, or an external JS identified by the AppEUI/JoinEUI).

The confusion is arising from the evolving name and semantics of that field.

At any rate, LW1.0.2 says: 

"The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame."

In my emails I’ve been highlighting the essential/underlined role of the AppEUI field. 

Alper

> On Jul 1, 2017, at 10:40 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
>> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Jul 2017 12:49:24 +0100

Hi Alper,

Sorry for the slow response, but I'm doing edits on this now so...

> In practice, it identifies the JS.

So my issue with saying that is that one JS will like be the JS
for many AppEUIs so it's an N:1 mapping between AppEUI and JS
identifiers (be those IP addresses or names), so saying that an
AppEUI "identifies" a JS seems wrong to me still.

Would it work for you if we say it like this:

"
AppEUI: IEEE EUI64 corresponding to the join server for an application
"

That also calls for a definition of the JS I guess, so I can
also add:

- Join Server: The Join Server (JS) is a server on the Internet
side of an NS that processes join requests from end-devices.

Cheers,
S.

Cheers,
S.