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

["weigengyu" <[e-mail]>]

Hi,

There is a question about Format in
draft-ietf-lpwan-ipv6-static-context-hc-04.

> So I think,  we need to maintain same order on all fragment headers.
> existing;
>       <------------ R ---------->
>                           <--T--> 1 <--N-->
>                +-- ... --+- ... -+-+- ... -+
>                | Rule ID | DTag  |W|  CFN  |
>                +-- ... --+- ... -+-+- ... -+
>
> shall be;
>      <------------ R ---------->
>                           <--T--> <--N--> 1
>                +-- ... --+- ... -+- ... -+-+
>                | Rule ID | DTag  |  CFN  |W|
>                +-- ... --+- ... -+- ... -+-+
>
> and for the last fragment
>    <------------ R ---------->
>                           <--T--> <--N-->
>                +-- ... --+- ... -+- ... -+-+
>                | Rule ID | DTag  |  CFN  |MIC
>                +-- ... --+- ... -+- ... -+-+
>
> what do you think?
>

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?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Carles Gomez Montenegro
Sent: Wednesday, June 21, 2017 12:01 AM
To: Arun
Cc: lp-wan ; Laurent Toutain ; Ana Minaburo
Subject: Re: [lp-wan] re-order header field request


Hi Arun,

Thanks for pointing this out.

Your proposal seems fine to me, except for the (possibly minor) detail
that in your proposal "R" would comprise a number of header fields for the
last fragment that would be different from the number of fields in
previous fragments.

Maybe we could also consider another solution: adding the W bit in the
header of the last fragment of the packet.

I haven't found examples of scenarios where the W bit is actually needed
in the last fragment (i.e. fragment with "all ones" CFN). However, I'm
wondering if there is an actual benefit or a related use case that may
require *not* having a W bit in the last fragment header. (If anyone has
any in mind, please chime in!)

On the other hand, if we have the W bit also in the last fragment header,
header format will be more uniform across all fragments.

Thoughts?

Cheers,

Carles




> Hi all,
> Absence of window bit in the last fragment of the packet makes it tricky
> to unmarshall the header at the receiver.
> As I see it, the receiver up front shall know the length of the CFN
> field depending on the Window size configured but doesn't know to
> anticipate the last fragment unless indicated by CFN.
> So I think,  we need to maintain same order on all fragment headers.
>
> existing;
>
>       <------------ R ---------->
>                           <--T--> 1 <--N-->
>                +-- ... --+- ... -+-+- ... -+
>                | Rule ID | DTag  |W|  CFN  |
>                +-- ... --+- ... -+-+- ... -+
>
> shall be;
>      <------------ R ---------->
>                           <--T--> <--N--> 1
>                +-- ... --+- ... -+- ... -+-+
>                | Rule ID | DTag  |  CFN  |W|
>                +-- ... --+- ... -+- ... -+-+
>
> and for the last fragment
>    <------------ R ---------->
>                           <--T--> <--N-->
>                +-- ... --+- ... -+- ... -+-+
>                | Rule ID | DTag  |  CFN  |MIC
>                +-- ... --+- ... -+- ... -+-+
>
>
> what do you think?
>
>
> thanks,
> Arun
>
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan
>


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