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

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:weigengyu@vip.sina.com] 
Sent: mardi 27 juin 2017 05:12
To: Pascal Thubert (pthubert) <pthubert@cisco.com>; Carles Gomez Montenegro <carlesgo@entel.upc.edu>
Cc: lp-wan@ietf.org; arun@ackl.io
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: lp-wan@ietf.org ; arun@ackl.io
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:lp-wan-bounces@ietf.org] On Behalf Of weigengyu
Sent: vendredi 23 juin 2017 16:26
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
Cc: lp-wan@ietf.org; arun@ackl.io
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: arun@ackl.io ; lp-wan@ietf.org
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

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan
_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan 