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

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

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?  

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? 

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.


Regards, 

Gengyu WEI
Network Technology Center
School of Computer 
Beijing University of Posts and Telecommunications

From: அருண்பிரபு (arunprabhu) 
Sent: Thursday, June 22, 2017 3:27 AM
To: weigengyu 
Cc: [e-mail] 
Subject: Re: [lp-wan] Fw: re-order header field request

Hi Gengyu,

On Jun 21, 2017 7:06 PM, "weigengyu" <[e-mail]> wrote:


  Hi Arun, 



    BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no fragment.
    In such cases, RuleID serves the purpose to identify if the incoming packet is a fragmented packet



  If a packet is fragmented, each fragment contain both Rule ID and Dtag as the draft defined.
  But, the receiver can know which Rule ID is used by the Dtag in the succesive fragments even in which Rule ID in not existed. 



    or if it's just came out of SCHC.



  If a packet is not fragmented, there is a Rule ID as a indication.
  Is there a Dtag? 
There is no Dtag  in this case.


  Regards,

  Gengyu WEI
  Network Technology Center
  School of Computer
  Beijing University of Posts and Telecommunications

  -----原始邮件----- From: Arun
  Sent: Wednesday, June 21, 2017 11:52 PM
  To: [e-mail] 

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

  Hi Gengyu,
  The flow shall be;

  BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no fragment.

  In such cases, RuleID serves the purpose to identify if the incoming
  packet is a fragmented packet or if it's just came out of SCHC. If we
  are sure that all the packets received will be fragmented then it makes
  sense to send ruleID at the beginning.

  hope that helps,
  Arun


  On 21/06/2017 17:10, weigengyu wrote:




    Hi Carles,

    Suppose that one packet is partitioned into two fragments.

    Because the Dtag indicates two fragments belonged to one packet,
    the Rule ID in the second fragment is repeated, or redundent, isn't it?

    If the Rule ID is not exist in the second fragment,
    the receiver can process it according to the Dtag which is the same in
    two fragments.
    Is there any confusions at the receiver side?

    Regards,

    Gengyu WEI
    Network Technology Center
    School of Computer
    Beijing University of Posts and Telecommunications
    -----原始邮件----- From: Carles Gomez Montenegro
    Sent: Wednesday, June 21, 2017 2:07 PM
    To: weigengyu
    Subject: Re: [lp-wan] Fw: re-order header field request


    Hi Gengyu,


      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?


    The Rule ID is needed to provide a receiver with information on what type
    of content is being carried (and how it has to be handled). Note that not
    all IPv6 packets will require fragmentation, and then losses may happen,
    also non-fragmented packets may be interleaved with fragments, etc.

    Cheers,

    Carles



      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 

  _______________________________________________
  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