From 6lowpan-bounces@ietf.org Tue Dec 05 22:58:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrnvV-0007vc-7U; Tue, 05 Dec 2006 22:58:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrnvU-0007vU-1G for 6lowpan@ietf.org; Tue, 05 Dec 2006 22:58:32 -0500 Received: from cs-smtp-2.stanford.edu ([171.64.64.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrnvS-0002zk-Lj for 6lowpan@ietf.org; Tue, 05 Dec 2006 22:58:32 -0500 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.100]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1GrnvQ-0002K0-Ql; Tue, 05 Dec 2006 19:58:29 -0800 In-Reply-To: <49A38D2FE2C53946A57916AD6A1F00D7139378@DKDN01MX34.danfoss.net> References: <49A38D2FE2C53946A57916AD6A1F00D7139378@DKDN01MX34.danfoss.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/mixed; boundary=Apple-Mail-8-239246557 Message-Id: <41715AED-23A8-4E72-B97C-4CF470E8805D@cs.stanford.edu> From: Philip Levis Subject: Re: [6lowpan] format document on the wiki Date: Tue, 5 Dec 2006 19:58:43 -0800 To: Schumacher Christian Peter Pii X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-2.Stanford.EDU X-Scan-Signature: 76176362e8f1b8c7f090a0575be4e607 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: cabo@tzi.org, 6lowpan@ietf.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: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org --Apple-Mail-8-239246557 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 29, 2006, at 12:47 PM, Schumacher Christian Peter Pii wrote: > Dear Lowpanners. > > Does anyone have comments for the format document on the wiki? > > Are the current implementers happy with this draft? > > Please speak up. > First off, I like that NALP was changed to 00xxxxxx. It is unlikely that 6lowpan will need all the bits, and it enables many other networks to inexpensively and easily interoperate. Making it easier to interoperate decreases the cost of adoption. I am not an expert on IANA considerations: is arbitration of the 00xxxxxx values under its purview? I have one concern with the current draft: the ordering of the fragmentation and mesh headers. In his presentation at IETF 67, Jonathan noted that the order followed the model presented by standard IPv6. In IPv6, fragmentation/reassembly must be end-to-end, so the ordering makes sense. However, this is sub-IP. I think that most of the real-world experiments with 15.4 radios, as well as basic loss models, suggest that per-hop fragmentation/reassembly is greatly preferable to e2e, particularly for energy reasons. You don't need to add a mesh header on each fragment, you have fewer retransmissions, and less state maintenance. Including a mesh routing header is essentially to provide IP routing; following the guidelines of RFC 2460 Section 5, I believe the order of these two headers should be reversed: a node fragments and reassembles a mesh packet on a per-hop basis, rather than routing an IPv6 datagram one fragment at a time. I've attached my simple C-based parsing code. It's not pretty and it's quite incomplete, but it covers the basic packet format considerations for the earlier draft. Phil --Apple-Mail-8-239246557 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0640; name=ipv6.c Content-Disposition: attachment; filename=ipv6.c typedef nx_struct message { cc2420_header_t hdr; uint8_t data[0]; } message_t; typedef ((void)(*)(message_t*, uint8_t*, uint8_t)) proto_process_t; // Initialize with proper protocol processing functions, be sure // to stick null handler in for unhandled protocols proto_process_t parse_proto[128]; void parse_fragment(message_t* packet, uint8_t* payload, uint8_t len) { uint16_t tag; uint16_t size; uint16_t offset; tag = (payload[0] & 0x1f) << 5; tag |= (payload[1] & 0xf8) >> 3; size = (payload[1] & 0x7) << 8; size |= payload[2]; if (payload[0] & 0xe == 0xe) { offset = payload[3]; payload = payload + 4; } else { offset = 0; payload = payload + 3; } // do reassembly here, if you want to... // check header ordering: don't have mesh within } void parse_mesh(message_t* packet, uint8_t* payload, uint8_t len) { // more robust implementation would check that we don't walk off // the end of a malicious packet by ensuring payload never grows // to more than payload + len uint8_t oBit = payload[0] & 0x20; uint8_t fBit = payload[0] & 0x10; uint8_t hopsLeft = payload[0] & 0xf; payload = payload + 1; uint64_t longO; uint64_t longF; uint16_t shortO; uint16_t shortF; if (hopsLeft == 0xf) { hopsLeft = payload[0]; payload = payload + 1; len--; } hopsLeft--; if (oBit) { memcpy(&longO, payload, 8); payload += 8; len -= 8; } else { memcpy(&shortO, payload, 2); payload += 2; len -= 2; } if (fBit) { memcpy(&longF, payload, 8); payload += 8; len -= 8; } else { memcpy(&shortF, payload, 2); payload += 2; len -= 2; } // Store addresses and hopsLeft in temporary storage for protocol // processing parse_packet(packet, payload, len); } void parse_packet(message_t* packet, uint8_t* payload, uint8_t len) { if (len == 0) {return;} uint8_t dispatch = payload[0]; if (dispatch & 0xc == 0xc) { parse_fragment(packet, payload, len); } else if (dispatch & 0x8) { parse_mesh(packet, payload, len); } else { parse_proto[dispatch](packet, payload + 1, len - 1); } } parse_proto[0x01] is just parsing IPv6 parse_proto[0x02] is just parsing HC1 parse_proto[0x02] is just parsing HC1 parse_proto[0x10] is just parsing BC0 parse_proto[0x7f] just calls alternative dispatch function array (if exists) --Apple-Mail-8-239246557 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --Apple-Mail-8-239246557-- From 6lowpan-bounces@ietf.org Mon Dec 11 02:16:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtfOt-0007yS-6D; Mon, 11 Dec 2006 02:16:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtfOr-0007yC-Op for 6lowpan@ietf.org; Mon, 11 Dec 2006 02:16:33 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtfOq-0003mN-Bc for 6lowpan@ietf.org; Mon, 11 Dec 2006 02:16:33 -0500 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JA300AAMLJ37X@mailout2.samsung.com> for 6lowpan@ietf.org; Mon, 11 Dec 2006 16:16:15 +0900 (KST) Received: from your655e9d6f61 ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JA300LT8LJ3MD@mmp1.samsung.com> for 6lowpan@ietf.org; Mon, 11 Dec 2006 16:16:15 +0900 (KST) Date: Mon, 11 Dec 2006 16:15:46 +0900 From: Daniel Park Subject: Re: [6lowpan] format document on the wiki To: Schumacher Christian Peter Pii , 6lowpan@ietf.org Message-id: <041e01c71cf4$2dea3470$6dc6dba8@your655e9d6f61> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <49A38D2FE2C53946A57916AD6A1F00D7139378@DKDN01MX34.danfoss.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org format document on the wikiTo WG, To me, I am still confusing the process of this issue. Strictly speaking, I don't mind the format itself. Rather, selecting one solution must happen as soon as possible. I don't want to speak up at this stage. Before that, please let us know the WG decision explicitely. Then, we will be able to come up with further details accordingly. In fact, the document shown in wiki is not an official document. Nothing can be a perfect solution. But, simplicity seems pretty much perfect approach. That's all at this stage in my mind. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: Schumacher Christian Peter Pii To: 6lowpan@ietf.org Cc: cabo@tzi.org Sent: Thursday, November 30, 2006 5:47 AM Subject: [6lowpan] format document on the wiki Dear Lowpanners. Does anyone have comments for the format document on the wiki? Are the current implementers happy with this draft? Please speak up. Regards Christian _______________________________________________ 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 From 6lowpan-bounces@ietf.org Mon Dec 11 15:50:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts6r-000187-Jt; Mon, 11 Dec 2006 15:50:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts6a-0000so-W4 for 6lowpan@lists.ietf.org; Mon, 11 Dec 2006 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gts6a-0006AX-Bw for 6lowpan@lists.ietf.org; Mon, 11 Dec 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 3652F2AC87; Mon, 11 Dec 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gts65-0007iX-VI; Mon, 11 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: 6lowpan@lists.ietf.org Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-format-07.txt 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low power WPAN Working Group of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.15.4 Networks Author(s) : G. Montenegro, et al. Filename : draft-ietf-6lowpan-format-07.txt Pages : 31 Date : 2006-12-11 This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-format-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-6lowpan-format-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-6lowpan-format-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-11141852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6lowpan-format-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6lowpan-format-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-11141852.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --NextPart-- From 6lowpan-bounces@ietf.org Mon Dec 11 15:51:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts77-0001r8-6M; Mon, 11 Dec 2006 15:51:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts6b-0000tJ-9t for 6lowpan@lists.ietf.org; Mon, 11 Dec 2006 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gts6a-0006Am-N6 for 6lowpan@lists.ietf.org; Mon, 11 Dec 2006 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 5A07C175E2; Mon, 11 Dec 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gts65-0007iR-TR; Mon, 11 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: 6lowpan@lists.ietf.org Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-problem-06.txt 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low power WPAN Working Group of the IETF. Title : 6LoWPAN: Overview, Assumptions, Problem Statement and Goals Author(s) : N. Kushalnagar, et al. Filename : draft-ietf-6lowpan-problem-06.txt Pages : 13 Date : 2006-12-11 This document describes the assumptions, problem statement and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-6lowpan-problem-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-6lowpan-problem-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-11141711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6lowpan-problem-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6lowpan-problem-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-11141711.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --NextPart-- From 6lowpan-bounces@ietf.org Wed Dec 13 15:51:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gub4A-0000oB-Ak; Wed, 13 Dec 2006 15:51:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gub48-0000ll-14 for 6lowpan@lists.ietf.org; Wed, 13 Dec 2006 15:51:00 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gub47-0002rl-0q for 6lowpan@lists.ietf.org; Wed, 13 Dec 2006 15:51:00 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id CFA7726E36; Wed, 13 Dec 2006 20:50:58 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gub3z-00068v-KM; Wed, 13 Dec 2006 15:50:51 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 13 Dec 2006 15:50:51 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: 6lowpan@lists.ietf.org Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-format-08.txt 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low power WPAN Working Group of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.15.4 Networks Author(s) : G. Montenegro, et al. Filename : draft-ietf-6lowpan-format-08.txt Pages : 31 Date : 2006-12-13 This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-format-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-6lowpan-format-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-6lowpan-format-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-13142754.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6lowpan-format-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6lowpan-format-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-13142754.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --NextPart-- From 6lowpan-bounces@ietf.org Wed Dec 13 19:32:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueWg-0005nt-QC; Wed, 13 Dec 2006 19:32:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueWg-0005no-AA for 6lowpan@lists.ietf.org; Wed, 13 Dec 2006 19:32:42 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GueWd-0006nn-U2 for 6lowpan@lists.ietf.org; Wed, 13 Dec 2006 19:32:42 -0500 Received: from [172.16.14.22] (a80-126-71-44.adsl.xs4all.nl [80.126.71.44]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id kBE0WWFj001885 for <6lowpan@lists.ietf.org>; Wed, 13 Dec 2006 17:32:34 -0700 (MST) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain Date: Wed, 13 Dec 2006 17:32:28 -0700 Message-Id: <1166056349.5614.62.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [6lowpan] WG last call on Format document 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Folks, This note formally starts the WG Last Call for comments on draft-ietf-6lowpan-format-08.txt, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-format-08.txt The document is intended to be submitted by this Working Group to the IESG for publication as an Informational Document. Please review the document carefully (one last time), and send your comments to the 6lowpan list. Please also indicate in your response whether or not you think this document is ready to go to the IESG. This Last Call will end on Thursday 4 January 2007 at 2359 UTC. Thanks, Geoff & Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Dec 14 01:40:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GukG7-000469-FY; Thu, 14 Dec 2006 01:39:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GukG6-000464-6k for 6lowpan@lists.ietf.org; Thu, 14 Dec 2006 01:39:58 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GukG4-0007B0-OV for 6lowpan@lists.ietf.org; Thu, 14 Dec 2006 01:39:58 -0500 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.100]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1GukG2-0002YH-6a; Wed, 13 Dec 2006 22:39:55 -0800 In-Reply-To: <1166056349.5614.62.camel@localhost> References: <1166056349.5614.62.camel@localhost> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [6lowpan] WG last call on Format document Date: Wed, 13 Dec 2006 22:40:13 -0800 To: Geoff Mulligan X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 9dddbef7dbf47a29383c7a3c8e5dce6e X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 6lowpan <6lowpan@lists.ietf.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: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Dec 13, 2006, at 4:32 PM, Geoff Mulligan wrote: > Folks, > This note formally starts the WG Last Call for comments on > draft-ietf-6lowpan-format-08.txt, "Transmission of IPv6 Packets over > IEEE 802.15.4 Networks". > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-format-08.txt > > The document is intended to be submitted by this Working Group to the > IESG for publication as an Informational Document. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. I still have a concern about the ordering of the fragmentation and mesh delivery headers. Can anyone offer a good argument on why fragmentation is within mesh and not vice versa? Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Dec 14 03:59:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GumQq-0007pZ-9Y; Thu, 14 Dec 2006 03:59:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GumQn-0007pD-PI for 6lowpan@lists.ietf.org; Thu, 14 Dec 2006 03:59:09 -0500 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GumQF-0001Z1-GW for 6lowpan@lists.ietf.org; Thu, 14 Dec 2006 03:59:09 -0500 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id kBE8wQXJ017595; Thu, 14 Dec 2006 09:58:26 +0100 (CET) In-Reply-To: References: <1166056349.5614.62.camel@localhost> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [6lowpan] WG last call on Format document Date: Thu, 14 Dec 2006 09:58:24 +0100 To: Philip Levis X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 6lowpan <6lowpan@lists.ietf.org>, Carsten Bormann 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org > I still have a concern about the ordering of the fragmentation and > mesh delivery headers. Can anyone offer a good argument on why > fragmentation is within mesh and not vice versa? I think the general rule is that a node should only have to parse the subheaders that it is concerned with. I'm assuming a mesh forwarder does not reassemble (I don't happen to know any good reason why it should). So a mesh forwarder is concerned with the forwarding header only; these therefore should come first. Only at the L2 destination is it necessary to peek further into the header, e.g. the fragmentation header for reassembly. Compare this with IPv6: The forwarding header (here the IP header) is in front of the fragmentation header, which is a destination header (only "opened" at the destination address set in the IP header). [WG chair hat on:] It is exactly this kind of issue that I like to see discussed at WGLC -- so please keep up sending in the questions! Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Dec 14 09:13:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurKf-0002KM-3Q; Thu, 14 Dec 2006 09:13:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurKd-0002KG-OK for 6lowpan@ietf.org; Thu, 14 Dec 2006 09:13:07 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GurKa-0008HX-8V for 6lowpan@ietf.org; Thu, 14 Dec 2006 09:13:07 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F23034F0001 for <6lowpan@ietf.org>; Thu, 14 Dec 2006 15:11:28 +0100 (CET) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 15:11:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Dec 2006 15:11:27 +0100 Message-ID: <6D34F0B7D5BCB246A42380744457CA3626D260@esealmw107.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Any reference implementation ? Thread-Index: Accfib7b2ZZe+GmGQpyHbwFkhRE85g== From: "Vlasios Tsiatsis XV \(KI/EAB\)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 14 Dec 2006 14:11:28.0066 (UTC) FILETIME=[BF1CBA20:01C71F89] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [6lowpan] Any reference implementation ? 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1680790121==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1680790121== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71F89.BF2E6C36" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71F89.BF2E6C36 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone,=20 If I recall corrent I saw an e-mail in the list that the group should = have two reference implementations ready before Christmas.=20 Is this true ? If yes are these implementations going to be publicly = available ? Thank you in advance, Vlasios -------------------------------- Vlasios Tsiatsis, Ph.D. Senior Research Engineer =09 IP Mobility Research, IP Networks =09 Ericsson Research Office: +46 8 757 15 29 SE-164 80 Stockholm, Sweden Fax: +46 8 404 70 20 Torshamnsgatan 23 Mobile: +46 761 05 05 29 www.ericsson.com e-mail: vlasios.xv.tsiatsis@ericsson.com ------_=_NextPart_001_01C71F89.BF2E6C36 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Any reference implementation ?

Hi everyone,
If I recall corrent I saw an e-mail in = the list that the group should have two reference implementations ready = before Christmas.

Is this true ? If yes are these = implementations going to be publicly available ?

Thank you in advance,
Vlasios

--------------------------------
Vlasios Tsiatsis, Ph.D.
Senior Research = Engineer        =         =        

IP Mobility Research, IP = Networks       =        
Ericsson = Research       =         =         =         Office:  +46 8=A0757 15 = 29
SE-164 80 Stockholm, = Sweden     =         =         Fax:     = +46 8=A0404 70 20
Torshamnsgatan = 23       =         =         =         Mobile: +46=A0761 05 05 = 29
www.ericsson.com        =         =         =         e-mail: = vlasios.xv.tsiatsis@ericsson.com


------_=_NextPart_001_01C71F89.BF2E6C36-- --===============1680790121== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1680790121==-- From 6lowpan-bounces@ietf.org Thu Dec 14 12:02:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GutyT-0000fN-S0; Thu, 14 Dec 2006 12:02:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GutyS-0000dQ-8y for 6lowpan@lists.ietf.org; Thu, 14 Dec 2006 12:02:24 -0500 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GutyP-0001Xv-Px for 6lowpan@lists.ietf.org; Thu, 14 Dec 2006 12:02:24 -0500 Received: from dnab42202a.stanford.edu ([171.66.32.42]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1GutyN-0002zs-6M; Thu, 14 Dec 2006 09:02:20 -0800 In-Reply-To: References: <1166056349.5614.62.camel@localhost> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21F0CDBA-E61A-42AF-AB72-115A874226B8@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [6lowpan] WG last call on Format document Date: Thu, 14 Dec 2006 08:46:30 -0800 To: Carsten Bormann X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: 54cb1bda8084ee4cdf52f72d94b5a886 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: 6lowpan <6lowpan@lists.ietf.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: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Dec 14, 2006, at 12:58 AM, Carsten Bormann wrote: >> I still have a concern about the ordering of the fragmentation and >> mesh delivery headers. Can anyone offer a good argument on why >> fragmentation is within mesh and not vice versa? > > I think the general rule is that a node should only have to parse > the subheaders that it is concerned with. > > I'm assuming a mesh forwarder does not reassemble (I don't happen > to know any good reason why it should). Energy. Imagine a theoretical route from N0 to NX of nodes N0, N1, N2, ... NX. Let us suppose that each link (NZ,NZ+1) has a packet loss rate of L. If you have no e2e fragment recovery, then an IPv6 packet P composed of F fragments has a ((1-L)^X)^F probability of successful delivery. The probability of any fragment being delivered successfully is (1-L)^X, and the probability of all of them being delivered successfully is (1-L)^X^F. It decreases exponentially with path length and packet size. With no fragment recovery, you have to resend the entire packet when this occurs. So the cost of a single fragment failure is FX transmissions and the overall cost to deliver a packet successfully is approximately FX + FX * (1-L)^-XF. With multihop reassembly, a single fragment loss requires control traffic to request the fragment, which itself also has a loss rate of (1-L)^X, then the fragment being retransmitted. So the cost of a single fragment failure is 2X transmissions, and the cost to deliver a packet successfully is approximately FX + 2FX * (1-L)^-X. With single-hop reassembly, each hop reassembles the packet as needed. Because losses are locally recovered, you do not have the exponential growth in packet loss. Unlike multihop recovery, where the number of packets transmitted is going to approximately be FX * ((1-L)^X)^-1, (the expected number of transmissions per packet is the inverse of the loss rate), in single-hop recovery the equation is multiplicative: FX* (1-L)^-1. Each link sends only (1-L)^-1 copies of its each fragment, with retransmissions caused by local failures. So the cost becomes FX + 2FX * (1-L)^-1. Recap: F is number of fragments X is length of route L is loss rate on each hop Multihop reassembly with full packet retransmission: FX + FX * (1-L)^-XF Multihop reassembly with fragment retransmission: FX + 2FX * (1-L)^-X Single-hop reassembly with fragment retransmission: FX + 2FX * (1-L)-1 Additionally, if you layer mesh on top of fragmentation, then every mesh packet has a fragmentation header in it. If the mesh header length is M and the fragment header length is G, then each fragment has M+G bytes added to it, for a total of F * (M + G). If you reverse the layering, then only the first fragment has the mesh header, and so you have a header cost of M + FG. Finally, it is (in my experience, others might differ on this) also easier to manage the state and retransmission policies, as reassembly does not have to worry about greatly different latencies caused by route changes between fragments. That being said, if X, F, and L are always going to be small, then the exponents don't matter. But there's a fundamental scalability problem. > So a mesh forwarder is concerned with the forwarding header only; > these therefore should come first. > Only at the L2 destination is it necessary to peek further into the > header, e.g. the fragmentation header for reassembly. > > Compare this with IPv6: The forwarding header (here the IP header) > is in front of the fragmentation header, which is a destination > header (only "opened" at the destination address set in the IP > header). > Two mails ago: I have one concern with the current draft: the ordering of the fragmentation and mesh headers. In his presentation at IETF 67, Jonathan noted that the order followed the model presented by standard IPv6. In IPv6, fragmentation/reassembly must be end-to-end, so the ordering makes sense. However, this is sub-IP. I think that most of the real-world experiments with 15.4 radios, as well as basic loss models, suggest that per-hop fragmentation/reassembly is greatly preferable to e2e, particularly for energy reasons. You don't need to add a mesh header on each fragment, you have fewer retransmissions, and less state maintenance. Including a mesh routing header is essentially to provide IP routing; following the guidelines of RFC 2460 Section 5, I believe the order of these two headers should be reversed: a node fragments and reassembles a mesh packet on a per-hop basis, rather than routing an IPv6 datagram one fragment at a time. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan