Re: [lp-wan] Fw: re-order header field request
"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Fri, 23 June 2017 10:48 UTC
Return-Path: <carlesgo@entel.upc.edu>
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 AC25C129353 for <lp-wan@ietfa.amsl.com>; Fri, 23 Jun 2017 03:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 9L0dONnVtjkn for <lp-wan@ietfa.amsl.com>; Fri, 23 Jun 2017 03:48:37 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726761200ED for <lp-wan@ietf.org>; Fri, 23 Jun 2017 03:48:37 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5NAmYrU041332; Fri, 23 Jun 2017 12:48:34 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 4F3AE1D53C1; Fri, 23 Jun 2017 12:48:33 +0200 (CEST)
Received: from 10.193.93.143 by webmail.entel.upc.edu with HTTP; Fri, 23 Jun 2017 12:48:02 +0200
Message-ID: <a219bb56a465ef882567adea7a9fdbff.squirrel@webmail.entel.upc.edu>
In-Reply-To: <341C683FEB8548B4924400501958BEAF@WeiGengyuPC>
References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <F5C7D3EBA1DD42858C339E13F435F7AC@WeiGengyuPC> <CAEW-XCC6WWU5Y0cG22c7OQriF3_2i2+MZe2j6xgpP4Rs5mnupw@mail.gmail.com> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC>
Date: Fri, 23 Jun 2017 12:48:02 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: weigengyu <weigengyu@vip.sina.com>
Cc: arun@ackl.io, lp-wan@ietf.org
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.99.2 at dash
X-Virus-Status: Clean
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Fri, 23 Jun 2017 12:48:34 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/PcSYsEdwyeZAyc5ivnMNQDU5hXg>
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: Fri, 23 Jun 2017 10:48:39 -0000
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] re-order header field request Arun
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request weigengyu
- [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request Arun
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request Laurent Toutain
- Re: [lp-wan] re-order header field request Arun
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request Arun
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request அருண்பிரபு (arunprabhu)
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] Fw: re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request Pascal Thubert (pthubert)
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] Fw: re-order header field request weigengyu
- [lp-wan] lpwan-overview comments Alper Yegin
- Re: [lp-wan] lpwan-overview comments Alexander Pelov
- Re: [lp-wan] lpwan-overview comments Alper Yegin
- Re: [lp-wan] Fw: re-order header field request Arun
- Re: [lp-wan] Fw: re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] Fw: re-order header field request Laurent Toutain
- Re: [lp-wan] lpwan-overview comments Stephen Farrell
- Re: [lp-wan] lpwan-overview comments Stephen Farrell
- Re: [lp-wan] lpwan-overview comments Alper Yegin
- Re: [lp-wan] lpwan-overview comments Stephen Farrell
- Re: [lp-wan] Fw: re-order header field request Pascal Thubert (pthubert)
- Re: [lp-wan] lpwan-overview comments Alper Yegin
- Re: [lp-wan] lpwan-overview comments Stephen Farrell