Subject: Re: [lp-wan] Fw: re-order header field request

From: "weigengyu" <[email-masked]>
Date: Wed, 21 Jun 2017 23:10:53 +0800

Hi Carles,

Suppose that one packet is partitioned into two fragments.

Because the Dtag indicates two fragments belonged to one packet,
the Rule ID in the second fragment is repeated, or redundent, isn't it?

If the Rule ID is not exist in the second fragment,
the receiver can process it according to the Dtag which is the same in two 
fragments.
Is there any confusions at the receiver side?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Carles Gomez Montenegro
Sent: Wednesday, June 21, 2017 2:07 PM
To: weigengyu
Subject: Re: [lp-wan] Fw: re-order header field request

Hi Gengyu,

> Why each successive fragment must contain a Rule ID?
> It is known that the DTag is used as an indication of fragments belonged
> to
> the same IPv6 packet.
> A Rule ID in the first fragement can be passed to the receiver how to do
> HC
> compression,
> but the successive fragments containing a Rule ID just send a redundent
> information to the receiver.
> Right?

The Rule ID is needed to provide a receiver with information on what type
of content is being carried (and how it has to be handled). Note that not
all IPv6 packets will require fragmentation, and then losses may happen,
also non-fragmented packets may be interleaved with fragments, etc.

Cheers,

Carles

> Regards,
>
> Gengyu WEI
> Network Technology Center
> School of Computer
> Beijing University of Posts and Telecommunications

---

From: Arun <[email-masked]>
Date: Wed, 21 Jun 2017 17:52:30 +0200

Hi Gengyu,
 The flow shall be;

BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no fragment.

 In such cases, RuleID serves the purpose to identify if the incoming
packet is a fragmented packet or if it's just came out of SCHC. If we
are sure that all the packets received will be fragmented then it makes
sense to send ruleID at the beginning.

hope that helps,
Arun

On 21/06/2017 17:10, weigengyu wrote:
> the receiver can process it according to the Dtag which is the same in
> two fragments.
> -----原始邮件----- From: Carles Gomez Montenegro
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: "weigengyu" <[email-masked]>
Date: Thu, 22 Jun 2017 01:06:11 +0800

Hi Arun,

> packet is a fragmented packet

If a packet is fragmented, each fragment contain both Rule ID and Dtag as 
the draft defined.
But, the receiver can know which Rule ID is used by the Dtag in the 
succesive fragments even in which Rule ID in not existed.

> or if it's just came out of SCHC.

If a packet is not fragmented, there is a Rule ID as a indication.
Is there a Dtag?

Regards,

Gengyu WEI
-----原始邮件----- 
From: Arun
Sent: Wednesday, June 21, 2017 11:52 PM
To: [email-masked]
Subject: Re: [lp-wan] Fw: re-order header field request

Hi Gengyu,
The flow shall be;

hope that helps,
Arun

---

From: அருண்பிரபு (arunprabhu) <[email-masked]>
Date: Wed, 21 Jun 2017 21:27:05 +0200

Hi Gengyu,

On Jun 21, 2017 7:06 PM, "weigengyu" <[email-masked]> wrote:

Hi Arun,

There is no Dtag  in this case.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- From: Arun
Sent: Wednesday, June 21, 2017 11:52 PM
To: [email-masked]

Hi Gengyu,
The flow shall be;

hope that helps,
Arun

---

From: "weigengyu" <[email-masked]>
Date: Thu, 22 Jun 2017 13:37:24 +0800

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?  

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? 

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.

Regards, 

Gengyu WEI

From: அருண்பிரபு (arunprabhu) 
Sent: Thursday, June 22, 2017 3:27 AM
To: weigengyu 
Cc: [email-masked] 
Subject: Re: [lp-wan] Fw: re-order header field request

Hi Gengyu,

  Hi Arun, 

    BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no fragment.
    In such cases, RuleID serves the purpose to identify if the incoming packet is a fragmented packet

  If a packet is fragmented, each fragment contain both Rule ID and Dtag as the draft defined.
  But, the receiver can know which Rule ID is used by the Dtag in the succesive fragments even in which Rule ID in not existed. 

  Regards,

  Gengyu WEI

  Hi Gengyu,
  The flow shall be;

  hope that helps,
  Arun

    Hi Carles,

    Regards,

    Gengyu WEI

    Hi Gengyu,

    Cheers,

    Carles

      Regards,

      Gengyu WEI

--------------------------------------------------------------------------------
_______________________________________________
lp-wan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lp-wan

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 23 Jun 2017 12:47:57 +0200

Hi,

> 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.

> Each fragment contains the same rule ID and Dtag.

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.

> 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: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 23 Jun 2017 12:48:02 +0200

Hi,

Thanks,

Carles

---

From: "weigengyu" <[email-masked]>
Date: Fri, 23 Jun 2017 22:25:53 +0800

Hi,

> successive data units are actual fragments or not, or how the data unit

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
-----原始邮件----- 
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,

Thanks,

Carles

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 Jun 2017 08:33:36 +0000

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,

> 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
-----原始邮件----- 
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,

Thanks,

Carles

---

From: "weigengyu" <[email-masked]>
Date: Tue, 27 Jun 2017 11:11:50 +0800

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
-----原始邮件----- 
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,

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.

Regards,

Gengyu WEI
-----原始邮件----- 
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,

Thanks,

Carles

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 27 Jun 2017 16:21:55 +0200

Hi Gengyu,

Thanks for your proposal, I see you are trying to reduce header overhead.
However, I'm afraid there are still issues with it.

In the context of the SCHC specification, an L2 LPWAN frame may carry an
unfragmented IPv6 datagram with a compressed header (see Fig. 4). The Rule
ID is the first field of the compressed IPv6 datagram.

When a compressed IPv6 datagram needs to be fragmented, then some Rule ID
space (of size R bits) is 'stolen' and used for fragmentation
functionality. So a requirement here is that whatever is defined for
fragmentation needs to be consistent with the format used for header
compression. Some special Rule ID (or set of Rule IDs in terms of R-bit
patterns) needs to be used to signal that a data unit being carried is a
fragment.

Note that we cannot risk communication failure due to e.g. loss of a first
fragment (which in your proposal carries a Rule ID) followed by other
fragments (which in your proposal do not carry a Rule ID) that are
actually received. In such case, a receiver may process the received data
units as e.g. unfragmented (compressed) IPv6 datagrams.

Cheers,

Carles

---

From: "weigengyu" <[email-masked]>
Date: Wed, 28 Jun 2017 09:49:49 +0800

Hi Carles,

> unfragmented IPv6 datagram with a compressed header (see Fig. 4).

This doc is just a draft.
The format in Fig.4 can be re-organized to get the suppression optimized.

> The Rule ID is the first field of the compressed IPv6 datagram.
Defining the first two bits are defined as an indications, these problems 
ara solved.

If it is 00, the fragment is the first and contains a Rule ID.
        If the Rule ID says this is an unfragment datagram, let it go;
        If the Rule ID says this is an fragmented one, you then get the 
Dtag.
If it is not 00, you need to get the Dtag for the fragment,
        and get the Rule ID by the Dtag.

> patterns) needs to be used to signal that a data unit being carried is a

It has been clarified that only one Rule ID is required for an IPv6 packets 
if it is framennted.
Or fragments belonged to one IPv6 packet just needs one Rule ID.
The Rule ID can be carried in the frist fragment to the receiver.
Only one is enough for conveying this information.

> units as e.g. unfragmented (compressed) IPv6 datagrams.

Could you explain how the receiver precesses fragments without getting the 
first fragment of an fragmented IPv6 packet?
No, it cannot by the current draft either.
Can you explain how the the current draft avoids the risk of communication 
failure due to e.g. loss of a first fragment?
It is not available to have each fragment processed independently by the 
current draft.

> In such case, a receiver may process the received data units as e.g. 
> unfragmented (compressed) IPv6 datagrams.
What is an unfragmented (compressed) IPv6 datagram?
If it is an unfragmented, it is the first, it contain the Rule ID.  Do you 
suppose it lost?

Regards,

Gengyu WEI
-----原始邮件----- 
From: Carles Gomez Montenegro
Sent: Tuesday, June 27, 2017 10:21 PM
To: weigengyu
Cc: [email-masked] ; [email-masked] ; Pascal Thubert (pthubert)
Subject: Re: [lp-wan] Fw: re-order header field request

Hi Gengyu,

Cheers,

Carles

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Jun 2017 10:05:51 +0300

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

---

From: Alexander Pelov <[email-masked]>
Date: Wed, 28 Jun 2017 09:56:10 +0200

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]> a écrit :
>

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Jun 2017 11:05:57 +0300

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.

Alper

> On Jun 28, 2017, at 10:56 AM, Alexander Pelov <[email-masked]> wrote:
> 
>> Le 28 juin 2017 à 09:05, Alper Yegin <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Arun <[email-masked]>
Date: Wed, 28 Jun 2017 11:49:53 +0200

Hi Gengyu,

I foresee fragmentation to be used mostly in the following scenarios;
  - firmware/software upgrade
  - configuration/device management
  - anything else ? which might require big packet sizes.
these are the scenarios that are occasional and they are'nt going to
happen quite often compared to the actual data transmission.

IIUYC, we will be consuming two additional bits for transmissions that
are more frequent thus negating the idea of suppressing ruleId in due
course of time.
Right ?

regards,
Arun

On 28/06/2017 03:49, weigengyu wrote:
> Defining the first two bits are defined as an indications, these
> problems ara solved.
>
> It has been clarified that only one Rule ID is required for an IPv6
> packets if it is framennted.
> Could you explain how the receiver precesses fragments without getting
> the first fragment of an fragmented IPv6 packet?
> Can you explain how the the current draft avoids the risk of
> communication failure due to e.g. loss of a first fragment?
> It is not available to have each fragment processed independently by
> the current draft.
>
> If it is an unfragmented, it is the first, it contain the Rule ID.  Do
> you suppose it lost?
>
>
> Regards,
>
> Gengyu WEI

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 28 Jun 2017 17:30:26 +0200

Hi Gengyu,

> No, it cannot by the current draft either.

The point is that with the current draft, if the first fragment is lost,
subsequent fragments cannot be confused with unfragmented IPv6 datagrams,
since all fragments have a Rule ID field that is set to a value that
indicates that the data unit being carried is a fragment.

> It is not available to have each fragment processed independently by the

Please see the response above.

> If it is an unfragmented, it is the first, it contain the Rule ID.  Do you

An unfragmented (compressed) IPv6 datagram is an IPv6 datagram which,
after SCHC header compression, has a size that does not exceed the maximum
L2 data unit payload size currently allowed. Therefore, it does not need
fragmentation.

Greetings,

Carles

---

From: Laurent Toutain <[email-masked]>
Date: Thu, 29 Jun 2017 09:48:01 +0200

Hi Gengyu,

The format is the following

 Rule ID  [Data Tag] CFN

CFN plays the role you assign to your 2 bits any value between [0, 2^N-2]
means more fragment and 2^N-1 no more fragment. It is more optimal than
using a specific bit in all frame.

Data Tag is not mandatory since in LPWAN you may have only one packet over
the air. That's a big difference with IEEE 802.15.4 or mesh networks where
a node can transmit several fragments belonging to different packet. In
LPWAN with duty cycles, this is not so common.

Rule ID is a specific value that tells the receiver this is a fragment. You
are right, the packet that have been fragmented contains at the first
position different rule ID which tells which rule must be used to
decompress the header. The following picture illustrate this.

    +---+------------------------------------------------------------+

    |Rid|  compressed header  |   payload                            |

    +---+-----+---------+---------+---------+---------+---------+----+

    |         |         |         |         |         |         |    |

+---+---------+     +---+---------+     +---+---------+     +---+----+

|R' |         |     |R' |         |     |R' |         |     |R' |    |

+---+---------+     +---+---------+     +---+---------+     +---+----+

              |         |         |         |         |         |

          +---+---------+     +---+---------+     +---+---------+

          |R' |         |     |R' |         |     |R' |         |

          +---+---------+     +---+---------+     +---+---------+

Laurent