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

["Pascal Thubert (pthubert)" <[e-mail]>]

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:[e-mail]] On Behalf Of weigengyu
Sent: vendredi 23 juin 2017 16:26
To: Carles Gomez Montenegro <[e-mail]>
Cc: [e-mail]; [e-mail]
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: [e-mail] ; [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/lp-wan