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

"weigengyu" <weigengyu@vip.sina.com> Tue, 27 June 2017 03:12 UTC

Return-Path: <weigengyu@vip.sina.com>
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A181286D6 for <lp-wan@ietfa.amsl.com>; Mon, 26 Jun 2017 20:12:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.46
X-Spam-Level:
X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN6CWRZ_Zjas for <lp-wan@ietfa.amsl.com>; Mon, 26 Jun 2017 20:12:02 -0700 (PDT)
Received: from smtp-6-47.vip.sina.com.cn (r3-63.sinamail.sina.com.cn [202.108.3.63]) by ietfa.amsl.com (Postfix) with SMTP id 4E75F1289C3 for <lp-wan@ietf.org>; Mon, 26 Jun 2017 20:12:01 -0700 (PDT)
Received: from unknown (HELO WeiGengyuPC)([114.246.135.90]) by vip.sina.com with ESMTP 27 Jun 2017 11:11:55 +0800 (CST)
X-Sender: weigengyu@vip.sina.com
X-Auth-ID: weigengyu@vip.sina.com
X-SMAIL-MID: 32757278581
Message-ID: <EE6304FA8F854718909CE5544B3F4D50@WeiGengyuPC>
From: weigengyu <weigengyu@vip.sina.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Carles Gomez Montenegro <carlesgo@entel.upc.edu>
Cc: lp-wan@ietf.org, arun@ackl.io
References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <F5C7D3EBA1DD42858C339E13F435F7AC@WeiGengyuPC> <CAEW-XCC6WWU5Y0cG22c7OQriF3_2i2+MZe2j6xgpP4Rs5mnupw@mail.gmail.com> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> <42e03b91c6a5e748a0c9d7d81966eef0.squirrel@webmail.entel.upc.edu> <3EE9A684758B44CE9FF891EFDBBF45BA@WeiGengyuPC> <0b52c5cefcbf45b9b3de78d35ae516ad@XCH-RCD-001.cisco.com>
In-Reply-To: <0b52c5cefcbf45b9b3de78d35ae516ad@XCH-RCD-001.cisco.com>
Date: Tue, 27 Jun 2017 11:11:50 +0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"; reply-type="original"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/Xrc-IqmEWRSvZQGz3rGv4tUoA6k>
Subject: Re: [lp-wan] Fw: re-order header field request
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" <lp-wan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lp-wan/>
List-Post: <mailto:lp-wan@ietf.org>
List-Help: <mailto:lp-wan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jun 2017 03:12:07 -0000

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
-----原始邮件----- 
From: Pascal Thubert (pthubert)
Sent: Monday, June 26, 2017 4:33 PM
To: weigengyu ; Carles Gomez Montenegro
Cc: lp-wan@ietf.org ; arun@ackl.io
Subject: Re: [lp-wan] Fw: re-order header field request

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:lp-wan-bounces@ietf.org] On Behalf Of weigengyu
Sent: vendredi 23 juin 2017 16:26
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
Cc: lp-wan@ietf.org; arun@ackl.io
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: arun@ackl.io ; lp-wan@ietf.org
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
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan
_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan