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

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

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