Re: [6lowpan] Proposal for DISCUSS Editorials
gabriel montenegro <gabriel_montenegro_2000@yahoo.com> Tue, 20 March 2007 07:14 UTC
Return-path: <6lowpan-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYYa-00015z-N8; Tue, 20 Mar 2007 03:14:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYYY-00015r-Or for 6lowpan@ietf.org; Tue, 20 Mar 2007 03:14:54 -0400
Received: from web81915.mail.mud.yahoo.com ([68.142.207.63]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTYYV-0005XE-Ng for 6lowpan@ietf.org; Tue, 20 Mar 2007 03:14:54 -0400
Received: (qmail 20219 invoked by uid 60001); 20 Mar 2007 07:14:51 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=y4vcgO2zz+RQ9t+z19FrScBZEUpJ5KCwV/IFMr9c7FpU5KAdJwwW6Q/oT9MZnGvxcCPzMv/lc4ikweqLaK0Rr+gMQDqBHdjKpO2Etj/MqzpQjvYbfKijzlCAvSaBEVOV30Vx1YpYhcaCJUWyf/xO7YbmSUyNAqmeB0bSU2Vu+m0=;
X-YMail-OSG: 4wGGowMVM1nVCx_7jBEn0dYLqMSOpYfuRRKxsAVJiyOrBX4ebaTftEWm9CGkWqBWRg--
Received: from [131.107.0.103] by web81915.mail.mud.yahoo.com via HTTP; Tue, 20 Mar 2007 00:14:51 PDT
X-Mailer: YahooMailRC/368.8 YahooMailWebService/0.6.132.8
Date: Tue, 20 Mar 2007 00:14:51 -0700
From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Subject: Re: [6lowpan] Proposal for DISCUSS Editorials
To: Carsten Bormann <cabo@tzi.org>, 6lowpan@ietf.org
MIME-Version: 1.0
Message-ID: <246097.19586.qm@web81915.mail.mud.yahoo.com>
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc
Cc: Carsten Bormann <cabo@tzi.org>
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1979125703=="
Errors-To: 6lowpan-bounces@ietf.org
inline marked "gab>" ----- Original Message ---- From: Carsten Bormann <cabo@tzi.org> To: 6lowpan@ietf.org Cc: Carsten Bormann <cabo@tzi.org> Sent: Monday, March 19, 2007 10:55:42 AM Subject: [6lowpan] Proposal for DISCUSS Editorials I'm proposing the following disposition of the editorial IESG comments that weren't in my previous message. Again, quick feedback is useful. Gruesse, Carsten ################################# * Editorial 1 From Gen-ART review by Joel Halpern: I don't know that I have ever seen a document before that says "thou shalt not extend this." (Section 5, last sentence before 5.1, "All headers used in LOWPAN adaptation layer SHALL be defined in this format document.") ===> INTERPRET COMMENT My view of this is that this is indeed the intention. Of course, evolving this spec itself should be possible. Note that this would require some version management, which will need to be addressed by bootstrapping. gab> sounds fine as a response to Joel. ################################# * Editorial 2 The fragmentation technique sends an offset that is in multiple of 8 bytes. It would be sensible to say that all fragments except the last SHOULD (MUST?) be multiple of eight bytes, so that the fragment offset works well. (section 5.3) ===> ACCEPT COMMENT AND CHANGE TEXT OLD: If an entire payload (e.g., IPv6) datagram fits within a single 802.15.4 frame, it is unfragmented and the LoWPAN encapsulation should contain no fragmentation header. If the datagram does not fit within a single IEEE 802.15.4 frame, it SHALL be broken into link fragments. The first link fragment SHALL contain the first fragment header (defined by one-bit as the first two bits and a zero-bit as the third bit) shown below. NEW: If an entire payload (e.g., IPv6) datagram fits within a single 802.15.4 frame, it is unfragmented and the LoWPAN encapsulation should contain no fragmentation header. If the datagram does not fit within a single IEEE 802.15.4 frame, it SHALL be broken into link fragments. As the fragment offset can only express multiples of eight bytes, all link fragments for a datagram except the last one MUST be multiples of eight bytes in length. The first link fragment SHALL contain the first fragment header (defined by one-bit as the first two bits and a zero-bit as the third bit) shown below. (This is a new MUST, but sensible implementations would have discarded non-aligned non-final fragments anyway because of the non-overlap mandate.) gab> I got rid of the "one-bit" and "zero-bit" business, as now there are more bits than that, and just said "as defined below". The relevant section now looks like this: fragments. As the fragment offset can only express multiples of eight bytes, all link fragments for a datagram except the last one MUST be multiples of eight bytes in length. The first link fragment SHALL contain the first fragment header defined as shown below. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 0 0| datagram_size | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: First Fragment ################################# * Editorial 3 At the beginning of section 10.1 on Encoding IPv6 Header fields, the wording is slightly misleading. The wording says "The following common IPv6 header values may be compressed from the onset..." I would suggest instead "The following IPv6 header values are expected to be common on 6lowPan networks, so the HC1 header has been constructed to efficiently compress them from the onset." ===> ACCEPT COMMENT AND CHANGE TEXT OLD: By virtue of having joined the same 6LoWPAN network, devices share some state. This makes it possible to compress headers even in the absence of the customary context-building phase. Thus, the following common IPv6 header values may be compressed from the onset: Version ... NEW: By virtue of having joined the same 6LoWPAN network, devices share some state. This makes it possible to compress headers without explicitly building any compression context state; 6lowpan header compression therefore does not keep any flow state, but relies entirely on information pertaining to the entire link. The following IPv6 header values are expected to be common on 6lowPan networks, so the HC1 header has been constructed to efficiently compress them from the onset: Version ... gab> Ok. Relevant section now looks like this: By virtue of having joined the same 6LoWPAN network, devices share some state. This makes it possible to compress headers without explicitly building any compression context state. Therefore, 6LoWPAN header compression does not keep any flow state. Instead, it relies on information pertaining to the entire link. The following IPv6 header values are expected to be common on 6LoWPAN networks, so the HC1 header has been constructed to efficiently compress them from the onset: Version is IPv6; both IPv6 source and destination ################################# * Editorial 4 Dan Romascanu: Comment [2007-03-05]: The following two Informative References do not seem to be used: [I-D.ietf-ipngwg-icmp-v3] Conta, A., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005. [I-D.ietf-ipv6-node-requirements] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node-requirements-11 (work in progress), August 2004. ===> REMOVE UNUSED REFERENCES gab> Done. Ran it through IDNits, nothing further found. ################################# * Editorial 5 Comment [2007-03-06]: Section 3, last paragrpah: The working group may pursue additional mechanisms as well. Is this the right document to state a possible direction of a WG? ===> REMOVE SENTENCE Done already. ################################# * HC editorial complex Magnus Westerlund: Discuss [2007-03-08]: Section 10.1: By virtue of having joined the same 6LoWPAN network, devices share some state. This makes it possible to compress headers even in the absence of the customary context-building phase. Thus, the following common IPv6 header values may be compressed from the onset: Version is IPv6; both IPv6 source and destination addresses are link local; the IPv6 interface identifiers (bottom 64 bits) for the source or destination addresses can be inferred from the layer two source and destination addresses (of course, this is only possible for interface identifiers derived from an underlying 802.15.4 MAC address); the packet length can be inferred either from layer two ("Frame Length" in the IEEE 802.15.4 PPDU) or from the "datagram_size" field in the fragment header (if present); both the Traffic Class and the Flow Label are zero; and the Next Header is UDP, ICMP or TCP. Currently this is written such as that one get the impression that these assumptions always will be true. Instead as it seems it should be interpret, in case the fields has the following values gains in HC can be made. ===> SEE EDITORIAL 3 ABOVE. COVERED. gab> Ok. The text is also confusing the reader if there exist a context state or not. For example: Preliminary context is often required. If so, it is highly desirable to allow building it by not relying exclusively on the in-line negotiation phase. For example, if we assume there is some manual configuration phase that precedes deployment (perhaps with human involvement), then one should be able to leverage this phase to set up context such that the first packet sent will already be compressed. ===> STRIKE THIS PARAGRAPH. gab> Done. There is also confusion about if several flows can be handled. Primarily due to the following: Existing work assumes that there are many flows between any two devices. Here, we assume that most of the time there will be only one flow, and this allows a very simple and low context flavor of header compression. ===> STRIKE PARAGRAPH gab> In my response to Magnus yesterday, I suggested some modified text. Since Magnus already ok-ed that text previous to your message, I will keep it. The modified text is as follows: Existing work assumes that there are many flows between any two devices. Here, we assume a very simple and low-context flavor of header compression. Whereas this works independently of flows (potentially several), it does not use any context specific to any flow. Thus, it cannot achieve as much compression as usual flow- aware schemes Please clarify that the compression is done totally without context and thus can handle any number of flows. ===> COVERED (EDITORIAL 3 ABOVE) gab> Ok. Section 10. Unfortuntate that this document wasn't announced on the ROHC WG list during its WGL last call. Based on that the description seems somewhat to thin to be easily implementable. I would propose that we delay the approval, update the draft and send it for an explicit review in ROHC. ===> SORRY. ROHC WG WAS AWARE ABOUT 6LOWPAN, BUT IT SHOULD HAVE BEEN ALERTED EXPLICITLY. HARD TO FIX NOW. NO NEED TO WAIT, THOUGH. gab> Please respond to Magnus about this, as he insisted on this point in his response to my message. Lars Eggert: Comment [2007-03-07]: Agree with Magnus' points about the header compression specification. ===> COVERED (ABOVE). gab> Ok. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan
- Re: [6lowpan] Proposal for DISCUSS Editorials gabriel montenegro
- [6lowpan] Proposal for DISCUSS Editorials Carsten Bormann