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

[Laurent Toutain <[e-mail]>]

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

On Wed, Jun 28, 2017 at 3:49 AM, weigengyu <[e-mail]> wrote:

>
> Hi Carles,
>
> In the context of the SCHC specification, an L2 LPWAN frame may carry an
>> 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.
>
> 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.
>>
>
> 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.
>
> 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.
>>
>
> 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
> Network Technology Center
> School of Computer
> Beijing University of Posts and Telecommunications
> -----原始邮件----- From: Carles Gomez Montenegro
> Sent: Tuesday, June 27, 2017 10:21 PM
> To: weigengyu
> Cc: [e-mail] ; [e-mail] ; Pascal Thubert (pthubert)
> Subject: Re: [lp-wan] Fw: re-order header field request
>
>
> 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
>
>
>
> 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
>>
>
> _______________________________________________
> 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
>