From 6lowpan-bounces@ietf.org Thu Jun 01 10:18:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flo00-0005mo-C9; Thu, 01 Jun 2006 10:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flnzz-0005mi-C6 for 6lowpan@ietf.org; Thu, 01 Jun 2006 10:18:07 -0400 Received: from mail2.iabg.de ([62.245.167.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flnzx-0007M0-2C for 6lowpan@ietf.org; Thu, 01 Jun 2006 10:18:07 -0400 Received: from mail2.iabg.de (localhost [127.0.0.1]) by localhost.iabg.de (Mailserver2 IABG) with ESMTP id 2ECD91139 for <6lowpan@ietf.org>; Thu, 1 Jun 2006 16:18:01 +0200 (CEST) Received: from exchange03.iabg.de (exchange03.iabg.de [10.128.200.37]) by mail2.iabg.de (Mailserver2 IABG) with ESMTP id 1C3AB1115 for <6lowpan@ietf.org>; Thu, 1 Jun 2006 16:18:01 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jun 2006 16:18:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6lowpan implementations Thread-Index: AcaFhjGgkLyX31rtRMazTqDKq5bvXA== From: "Mayer Karl" To: <6lowpan@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [6lowpan] 6lowpan implementations 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 Hi All, We have been investigating IP over 802.15.4 since some time and perform currently tests with IPv4 over 802.15.4 (using the uIP stack of SICS). The 6lowpan activities are very interesting for us and we are looking for public available code/implementations we can use for our investigations and tests. Since there is an 6lowpan testbed (www.6lowpan.org) there is obviously already code available but we are not sure whether it's open. So could anyone point me to available implementations/code? Thank you and best regards, Karl=20 --------------------------- Karl Mayer Technical Consultant IABG mbH Department for Information & Communication Einsteinstr. 20 85521 Ottobrunn Tel.: +49 89 6088 2066 Fax.: +49 89 6088 132066 E-mail: mayer@iabg.de _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 06 04:01:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnWUr-0002DZ-Qi; Tue, 06 Jun 2006 04:01:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnWUq-0002DT-C1 for 6lowpan@ietf.org; Tue, 06 Jun 2006 04:01:04 -0400 Received: from violet.upc.es ([147.83.2.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnWUn-0007qn-MM for 6lowpan@ietf.org; Tue, 06 Jun 2006 04:01:04 -0400 Received: from violet.upc.es (localhost [127.0.0.1]) by violet.upc.es (8.13.6/8.13.6) with ESMTP id k5680uxw009746; Tue, 6 Jun 2006 10:00:56 +0200 Received: from localhost (wmail-mat.upc.es [147.83.39.70]) by violet.upc.es (8.13.6/8.13.6) with ESMTP id k5680kIg009688; Tue, 6 Jun 2006 10:00:47 +0200 Received: from 147.83.39.92 ( [147.83.39.92]) as user peres@mat.upc.es by wmail-mat.upc.es with HTTP; Tue, 6 Jun 2006 09:59:13 +0200 Message-ID: <1149580753.448535d18019e@wmail-mat.upc.es> Date: Tue, 6 Jun 2006 09:59:13 +0200 From: Pere Salvatella To: Mayer Karl Subject: Re: [6lowpan] 6lowpan implementations References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 147.83.39.92 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: 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 Hi Karl, Our group, Wireless Network Group of the Technical University of Catalonia, is currently working on a 6lowpan scheme over IEEE 802.15.4 networks, with interest on the field of sensor networks. Our current work is based on a minor implementation of IETF 6lowpan WG directives, an mainly hold on a base of contributions from TinyOS community. The current implementation runs over TinyOS and it’s been tested over commercial TelosB research platform. The main IP stack is based on the adaptation made by HP Labs of the reduced uIP stack of SICS, but updated to work on an Adhoc environment based on FFD (compared to HPLabs which based its facilities on a FFD acting as an access point for a network of RFD) and to fulfill the points stated on the different drafts released. Currently our implementation have: - reduced IPv4 stack (mainly based on uIP of SICS) - 6lowpan header (without header compression neither fragmented paquets) - 6lowpan routing with DYMO and LOAD implementation - Nowadays we are using short addresses inside the PAN. We are working on: - Add packet fragmentation and header compression - adapting reduced IP stack to IPv6. - Usage of IPv6 link addresses - Add an autoconfiguration short address scheme based on 6lowpan directives We haven’t published yet any results neither code as opensource. Currently we are debugging but we plan to release the code soon. If you are interested on it, we can provide it to you. Pere Mensaje citado por Mayer Karl : > Hi All, > > We have been investigating IP over 802.15.4 since some time and perform > currently tests with IPv4 over 802.15.4 (using the uIP stack of SICS). > The 6lowpan activities are very interesting for us and we are looking > for public available code/implementations we can use for our > investigations and tests. Since there is an 6lowpan testbed > (www.6lowpan.org) there is obviously already code available but we are > not sure whether it's open. So could anyone point me to available > implementations/code? > > Thank you and best regards, > Karl > > --------------------------- > Karl Mayer > Technical Consultant > IABG mbH > Department for Information & Communication > Einsteinstr. 20 > 85521 Ottobrunn > > Tel.: +49 89 6088 2066 > Fax.: +49 89 6088 132066 > E-mail: mayer@iabg.de > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > ************************************************* Pere Salvatella Renart Wireless Networks Group Technical University of Catalonia (UPC). Spain peres@entel.upc.edu ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 07 03:48:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnsmR-0006XZ-Qy; Wed, 07 Jun 2006 03:48:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnsmQ-0006XU-ID for 6lowpan@ietf.org; Wed, 07 Jun 2006 03:48:42 -0400 Received: from natnoddy.rzone.de ([81.169.145.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnsmQ-00043x-0v for 6lowpan@ietf.org; Wed, 07 Jun 2006 03:48:42 -0400 Received: from aschemobil (p549F4266.dip0.t-ipconnect.de [84.159.66.102]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k577mbGC017577; Wed, 7 Jun 2006 09:48:38 +0200 (MEST) From: "David Rahusen" To: "'Ian Chakeres'" , "'Mario Mao'" , <6lowpan@ietf.org> Subject: AW: [6lowpan] Comments about the use of Multicast Ability Date: Wed, 7 Jun 2006 09:48:39 +0200 Organization: STZEDN Message-ID: <000001c68a06$cb6b94e0$1801a8c0@aschemobil> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ88A0TqcAXNno+Q2eF991sO+nufgNEYG8g In-Reply-To: <374005f30605210901x2b13d378k8c92fcc384172e98@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rahusen@stzedn.de 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 Hi all, I'm pretty new to this WG, so please correct me if I've been overlooking anything. I agree with Mario, that another protocol or even more complexity isn't reasonable for low power nodes. But multicast may be a useful solution = for some applications. In case of different PANs within one network, it is possible to transmit messages to anyone of a single PAN: Isn't it multicast? We know that all associated nodes within this PAN are directly reachable by the = appropriate coordinator. The main problem is, to reach this PAN (multi-hop). So my question is: Is it possible to specify a flag within the header of the adaptation layer to indicate, whether this message is a multicast = message or not? Therefore this message could be routed and transmitted as unicast = to the appropriate PAN coordinator. In case this flag is set, the = coordinator broadcasts the message within the PAN. Otherwise, the message is = directed to the coordinator itself. Please let me know if I'm totally wrong or this may be an approach. Best regards, David -----Urspr=FCngliche Nachricht----- Von: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 Gesendet: Sonntag, 21. Mai 2006 18:01 An: Mario Mao; 6lowpan@ietf.org Betreff: Re: [6lowpan] Comments about the use of Multicast Ability I think that a protocol like SMF (draft-ietf-manet-smf-02.txt) for = non-group based simple multicast would be appropriate for 6lowpan. The SMF draft = deals mainly with duplicate packet detection (DPD). Though it should be used = in conjunction with another algorithm to determine an optimized relay set. That brings me to another point, to support mutlicast I think the = adaptation layer should have a sequence number for multicast packets. This will be used to detect duplicate packets. SMF defines a IPv6 hop by = hop option to assist DPD, this field should be integrated into the shim = layer. Ian Chakeres On 5/20/06, Mario Mao wrote: > > > Hi all: > There is some comments about recently introduced Multicast = ability. > > I have read Format-02 document and the Carsten's mail about=20 > addressing map for 16-bit addresses. I think it is a good solution for = > the address confusion problem. > However, looks like there needs other precondition to make Multicast=20 > work properly and effectively in 6LowPAN. > > First condition is the MAC filter, as I mentioned in last mail,=20 > IEEE > 802.15.4 > MAC can't fliter Multicast frame, the reception and rejection=20 > algorithm are descripted as bellow in specification: > - If a destination PAN identifier is included in the frame, it shall=20 > match macPANId or shall be the broadcast PAN identifier (0 x ffff). > - If a short destination address is included in the frame, it shall=20 > match either macShortAddress or the broadcast address (0 x ffff).=20 > Otherwise, if an extended destination address is included in the=20 > frame, it shall match aExtendedAddress. > According to this algorithm, when the MAC layer of some 802.15.4=20 > node receive a frame with Multicast destination address, how will it=20 > judge the frame should be handled but not be discarded? For 802.15.4=20 > MAC PIB could just hold one 64-bits > EUI-64 address and one 16-bits short address(for node's unicast=20 > address), may be the only way to get Multicast frame is to set the MAC = > sublayer to promiscuous mode. > By doing this job, Adaptation Layer could get all of frame arrived in=20 > MAC sublayer and filter what it want by itself, including Multicast=20 > frame. > Unfortunately, the solution for the previous problem also cause=20 > another problem. > That is how to foward the Multicast frame to right destinations(group=20 > members). The document "6LoWPAN Meeting 65 IETF Dallas Format Document = > changes" > mentioned following possible method: dumb flooding, controlled=20 > flooding and unicasting to the PAN COORDINATOR. As my understanding,=20 > all three above still need > 802.15.4 MAC broadcast and Adapatation Layer broadcast flooding relay=20 > to make all possible receiver get Multicast frame. The requirement of=20 > Adapatation Layer broadcast flooding relay is because not all of=20 > 802.15.4 node will be in the broadcast range of the sender in Mesh=20 > Topology, unlike in Ethernet. So, maybe we should need an Adaptation=20 > Multicast Route Potocol(like PIM-SM in Internet) to build a Multicast=20 > Tree when some node join some Multicast group. After the Multicast=20 > tree has been built, node in the tree will know where are the group=20 > members in and how to forward Multicast frame to them. > In the matter of fact, we could also use the special Multicast=20 > address in a much simple way, that is just make Adaptation Layer be a=20 > Multicast frame filter. > In this way, > IPv6 Layer will tell Adaptation Layer which Multicast group it has=20 > joined, and Adaptation Layer will discard the frame not belong to=20 > these groups before handing it to IP Layer. However, if we want the=20 > sepcial Multicast address really do some work, controlled forwarding=20 > in Multicast Tree may be necessary. Otherwise, node will fill=20 > Multicast MAC address in Adaptation or MAC header but could only=20 > broadcast Multicast frame to all the node in the PAN. > > Actually, I think 6LowPANers will find a good way to solve the=20 > multicast problem eventually. But what I want to say is does it worth? = > For 802.15.4 MAC don't support multicast, we have to do all the work=20 > in Adaptation Layer. In LowPAN node, resource is limited(except=20 > energy, memory for code is tight either). If we make the protocol more = > complex, more code space will be needed. Take the platform we are=20 > using as an example, the Freescale MC9S08GB60 MCU has 60K Flash for=20 > code, hardware driver and 802.15.4 MAC library(supplied by Freescale)=20 > will take at least 33K, current Adaptation Layer will take about=20 > 12K(including Route and Topology Maintenance), this means only 15K is=20 > left for IPv6, NDP and up-layer. For our lab has implemented an=20 > IPv6/IPv4 dual protocol stack in ARM platform before, we consider 15K=20 > code space is very tight for a reduced IPv6 stack. The point is, if we = > could just use MAC broadcast to let IP Multicast work well, why not=20 > just do it? If we add more and more function to Adaptation Layer, I=20 > really worry about a low power and low cost device having the ability=20 > to run it. > > Thanks. > > Regards, > > Mario Mao > _______________________________________________ > 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 07 08:18:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnwzg-00046E-1U; Wed, 07 Jun 2006 08:18:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnwze-000469-Er for 6lowpan@ietf.org; Wed, 07 Jun 2006 08:18:38 -0400 Received: from nz-out-0102.google.com ([64.233.162.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnwzd-0001R5-Nf for 6lowpan@ietf.org; Wed, 07 Jun 2006 08:18:38 -0400 Received: by nz-out-0102.google.com with SMTP id f1so146289nzc for <6lowpan@ietf.org>; Wed, 07 Jun 2006 05:18:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:to:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole:from; b=R7rA5xBYDv6Qp4za3XEfpF2k4IG8BPqE19aWH30A5eDP78VIn06OLi9oC29aXQAigrLoSfIIuqiZhw0KS0nDQkExXGXKE86aba2WI5dzcN6laJGVe+cCSDkqcsSj2XE+6+lr4ycn7h2ZCFubmYm69MaZtJUbqm8wfh5H1ceUJ8E= Received: by 10.36.215.18 with SMTP id n18mr643679nzg; Wed, 07 Jun 2006 05:18:37 -0700 (PDT) Received: from Maoer ( [211.144.102.60]) by mx.gmail.com with ESMTP id 5sm1030674nzk.2006.06.07.05.18.34; Wed, 07 Jun 2006 05:18:37 -0700 (PDT) Message-ID: <000d01c68a2d$09810690$7fc0a8c0@netlab.cs.ecnu.edu.cn> To: , <6lowpan@ietf.org> References: <000001c68a06$cb6b94e0$1801a8c0@aschemobil> Subject: Re: [6lowpan] Comments about the use of Multicast Ability Date: Wed, 7 Jun 2006 20:22:18 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 From: Mario Mao X-Spam-Score: 1.2 (+) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: 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="===============1576101970==" Errors-To: 6lowpan-bounces@ietf.org --===============1576101970== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Nkxvd1BBTmVyOg0KDQpBcyBEYXZpZCBtZW50aW9uZWQsIG11bGl0Y2FzdCBpcyBkZWZpbml0ZWx5 IG5lZWRlZCBpbiA2TG93UEFOLiBNeSBwcmV2aW91cw0KY29tbWVudHMganVzdCB3YW50IHRvIGdp dmUgb3V0IHNvbWUgaWRlYSBhYm91dCB0aGUgcHJvYmxlbSB1c2luZyBNQUMgDQptdWx0aWNhc3Qu IEluIHRoZSBtYXR0ZXIgb2YgZmFjdCwgb3VyIGxhYiBoYXZlIGludHJvZHVjZWQgYW4gY29udHJv bGxlZCBmbG9vZGluZyANCnRvIHNvbHZlIHRoZSBJUCBtdWx0aWNhc3QgcHJvYmxlbSByZWNlbnRs eS4NCg0KVGhlIGZsb29kaW5nIHdheSBpcyBzaW1wbGU6IGFsbCBJUCBwYWNrZXQgd2l0aCBtdWx0 aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyB3aWxsDQogYmUgZW5jYXBzdWxlZCBpbiBhbiBhZGFw dGF0aW9uIEJyb2FkY2FzdCBGcmFtZS4gSG93ZXZlciwgdGhlIGZvcm1hdCBvZiANCmFkYXB0YXRp b24gQnJvYWRjYXN0IEZyYW1lIGlzIHNvbWV3aGF0IGRpZmZlcmVudCBmcm9tIHRoZSBzdGFuZGFy ZCBoZWFkZXIgDQpmb3JtYXQuIFRoZSBtb2RpZmllZCBmb3JtYXQgc2hvd2VkIGJlbG93Lg0KDQog ICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMN CiAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxDQogKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiB8IExGfCAgcHJvdF90eXBlICAgIHxNfEJ8IHJzdiAgIHxQ YXlsb2FkIChvciBNRC9Ccm9hZGNhc3QgSGRyKS4uLg0KICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCkFzIHRoZSBmaWd1 cmUgc2hvd2VkLCBhICJCIiBiaXQgaXMgYWRkZWQocmVwbGFjaW5nIG9uZSByc3YgYml0KS4gV2hl biB0aGUgIkIiIA0KYml0IGlzIHNldCwgYSBCcm9hZGNhc3QgRmllbGQgd2lsbCBiZSBpbmNsdWRl ZCBpbiB0aGUgZnJhbWUgaW1tZWRpYXRlbHkgZm9sbG93aW5nDQogdGhlIExvV1BBTiBoZWFkZXIu IElmIHRoZXJlIGlzIGEgQnJvYWRjYXN0IEZpZWxkLCB3ZSB3aWxsIGNhbGwgdGhlIA0KYWRhcHRh dGlvbiBmcmFtZSBhcyBhIEJyb2FkY2FzdCBGcmFtZS4gVGhlICJCcm9hZGNhc3QiIGZpZWxkIGlz IGRlZmluZWQgYXMgDQpmb2xsb3dzDQoNCiAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAg ICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgfFN8QnJv YWQgUmFkaXVzIHxTZXF1ZW5jZSBOdW1iZXJ8U291cmNlIEFkZHJlc3MsIGZvbGxvd2VkIGJ5Li4u DQogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQoNClM6IDAgaWYgdXNlIEVVSS02NCBhZGRyZXNzLCBvciAxIGlmIHVzZSAx Ni1iaXQgYWRkcmVzcy4NCkJyb2FkIFJhZGl1czogQnJvYWRjYXN0IFJhZGl1cywgNyBiaXRzLCBz aG91bGQgYmUgZGVjcmVtZW50IGJ5IGVhY2ggDQpicm9hZGNhc3QgcmVsYXkgbm9kZSwgaWYgaXQg aXMgZGVjcmVtZW50ZWQgdG8gMCwgZGlzY2FyZCB0aGUgZnJhbWUuDQpTZXF1ZW5jZSBOdW1iZXI6 IEEgOC1iaXQgbnVtYmVyIHRvIGlkZW50aWZ5IGRpZmZlcmVudCBCcm9hZGNhc3QgRnJhbWUgZnJv bQ0KdGhlIHNhbWUgc291cmNlIG5vZGUuIFRoZSBvcmlnaW5hdG9yIHdpbGwgaW5jcmVtZW50IHRo ZSBmaWVsZCBhZnRlciBlYWNoIA0Kc2VuZGluZy4NClNvdXJjZSBBZGRyZXNzOiBUaGUgT3JpZ2lu YXRvcidzIE1BQyBhZGRyZXNzLg0KDQpXaXRoIHRoZSBzdXBwb3J0IG9mIHRoZSAiQnJvYWRjYXN0 IiBmaWVsZCwgYW4gb3JpZ2luYXRvciBvciBhIHJlbGF5IG5vZGUgd2lsbCANCnNlbmQgdGhlIEJy b2FkY2FzdCBGcmFtZSBsaWtlIHRoYXQ6IGZpcnN0LCBkZWxpdmVyIHRoZSBmcmFtZSB0byBhbGwg Q29vcmRpbmF0b3IgDQphbmQgUm91dGVycyBhcm91bmQgdXNpbmcgTUFDIGJyb2FkY2FzdCh3aXRo IHRoZSBNQUMgZGVzdGluYXRpb24gYWRkcmVzcw0KIHNldCB0byAweEZGRkYsIGp1c3QgbmVlZCBi cm9hZGNhc3Qgb25jZSksIHRoZW4sIGlmIHRoZXJlIGFyZSBFbmQgRGV2aWNlcyBpbiANCnRoZSBu b2RlJ3MgbmVpZ2hib3IgdGFibGUsIHVuaWNhc3QgdGhlIGZyYW1lIHRvIHRoZW0gb25lIGJ5IG9u ZS4gQmVzaWRlcywgdG8gDQphdm9pZCBicm9hZGNhc3Qgc3Rvcm0sIGEgQnJvYWRjYXN0IFJlY29y ZCBUYWJsZSB3aWxsIGJlIG5lZWRlZC4gVGhlIHRhYmxlIHdpbGwgDQpyZWNvcmQgdGhlIFNvdXJj ZSBBZGRyZXNzIGFuZCBTZXF1ZW5jZSBOdW1iZXIgaW4gIkJyb2FkY2FzdCIgZmllbGQgb2YgZWFj aCANCnJlY2VpdmVkIEJyb2FkY2FzdCBGcmFtZSBhZnRlciByZS1icm9hZGNhc3RpbmcgaXQgZmly c3QoRW5kIERldmljZSBkb24ndCBuZWVkDQogdG8gcmUtYnJvYWRjYXN0aW5nKS4gU2VxdWVudGlh bGx5LCBhIEJyb2FkY2FzdCBWYWxpZCBUaW1lIHdpbGwgYmUgaW5pdGlhbGl6ZWQgZm9yIA0KdGhl IG5ld2x5IGFkZGVkIEJyb2FkY2FzdCBSZWNvcmQgRW50cnkuIFRoZW4sIGJlZm9yZSB0aGUgZW50 cnkgaXMgdGltZWQgb3V0IA0KKEJyb2FkY2FzdCBWYWxpZCBUaW1lIGlzIGRlY3JlbWVudGVkIHRv IDApLCBhbGwgQnJvYWRjYXN0IEZyYW1lIHdpdGggdGhlIHNhbWUgDQpTb3VyY2UgQWRkcmVzcyBh bmQgU2VxdWVuY2UgTnVtYmVyIHNob3VsZCBiZSBkaXNjYXJkZWQgYnV0IG5vdCByZWxheWVkLg0K DQpJbiBwcmFjdGljZSwgd2l0aCB0aGUgcmVsYXRpdmVseSBzaW1wbGUgd2F5LCB0aGUgY29udHJv bGxlZCBmbG9vZGluZyBjb3VsZCBqdXN0IA0Kc29sdmUgdGhlIHByb2JsZW0gb2YgaG93IHRvIG11 bHRpY2FzdGluZy4gV2UgZmluZCBpdCBzdGlsbCBhIGhpZ2gtY29zdGluZyBtZXRob2QNCiB0byBi cm9hZGNhc3QgcGVyaW9kaWMgTXVsdGljYXN0IElQIHBhY2tldChsaWtlIFJvdXRlciBBZHZlcnRp c2VtZW50LCANClJGQzI0NjEpLiBTbywgbW9yZSBkZXRhaWxzIGFib3V0IHRoZSB1cC1sYXllciBw cm90b2NvbChlc3BlY2lhbGx5IGFib3V0IA0KTkRQKSBuZWVkIGJlIGNvbnNpZGVyZWQuIEZvciBl eGFtcGxlLCB1c2luZyBhbiBkeW5hbWljIGFkdmVydGlzaW5nIA0KYWxnb3JpdGhtIHRvIHJlZHVj ZSB0aGUgYnJvYWRjYXN0IHRpbWVzLg0KDQpIb3BlIHRoZXNlIGlkZWFzIHdpbGwgZG8gc29tZSBo ZWxwLg0KDQpSZWdhcmRzLA0KDQpNYXJpbyBNYW8NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCkZyb206ICJEYXZpZCBSYWh1c2VuIiA8cmFodXNlbkBzdHplZG4uZGU+DQpUbzogIidJ YW4gQ2hha2VyZXMnIiA8aWFuLmNoYWtlcmVzQGdtYWlsLmNvbT47ICInTWFyaW8gTWFvJyIgPG1h cmlvbWFvQGdtYWlsLmNvbT47IDw2bG93cGFuQGlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBK dW5lIDA3LCAyMDA2IDM6NDggUE0NClN1YmplY3Q6IEFXOiBbNmxvd3Bhbl0gQ29tbWVudHMgYWJv dXQgdGhlIHVzZSBvZiBNdWx0aWNhc3QgQWJpbGl0eQ0KDQoNCkhpIGFsbCwNCg0KSSdtIHByZXR0 eSBuZXcgdG8gdGhpcyBXRywgc28gcGxlYXNlIGNvcnJlY3QgbWUgaWYgSSd2ZSBiZWVuIG92ZXJs b29raW5nDQphbnl0aGluZy4NCkkgYWdyZWUgd2l0aCBNYXJpbywgdGhhdCBhbm90aGVyIHByb3Rv Y29sIG9yIGV2ZW4gbW9yZSBjb21wbGV4aXR5IGlzbid0DQpyZWFzb25hYmxlIGZvciBsb3cgcG93 ZXIgbm9kZXMuIEJ1dCBtdWx0aWNhc3QgbWF5IGJlIGEgdXNlZnVsIHNvbHV0aW9uIGZvcg0Kc29t ZSBhcHBsaWNhdGlvbnMuDQoNCkluIGNhc2Ugb2YgZGlmZmVyZW50IFBBTnMgd2l0aGluIG9uZSBu ZXR3b3JrLCBpdCBpcyBwb3NzaWJsZSB0byB0cmFuc21pdA0KbWVzc2FnZXMgdG8gYW55b25lIG9m IGEgc2luZ2xlIFBBTjogSXNuJ3QgaXQgbXVsdGljYXN0PyBXZSBrbm93IHRoYXQgYWxsDQphc3Nv Y2lhdGVkIG5vZGVzIHdpdGhpbiB0aGlzIFBBTiBhcmUgZGlyZWN0bHkgcmVhY2hhYmxlIGJ5IHRo ZSBhcHByb3ByaWF0ZQ0KY29vcmRpbmF0b3IuIFRoZSBtYWluIHByb2JsZW0gaXMsIHRvIHJlYWNo IHRoaXMgUEFOIChtdWx0aS1ob3ApLiBTbyBteQ0KcXVlc3Rpb24gaXM6IElzIGl0IHBvc3NpYmxl IHRvIHNwZWNpZnkgYSBmbGFnIHdpdGhpbiB0aGUgaGVhZGVyIG9mIHRoZQ0KYWRhcHRhdGlvbiBs YXllciB0byBpbmRpY2F0ZSwgd2hldGhlciB0aGlzIG1lc3NhZ2UgaXMgYSBtdWx0aWNhc3QgbWVz c2FnZSBvcg0Kbm90PyBUaGVyZWZvcmUgdGhpcyBtZXNzYWdlIGNvdWxkIGJlIHJvdXRlZCBhbmQg dHJhbnNtaXR0ZWQgYXMgdW5pY2FzdCB0bw0KdGhlIGFwcHJvcHJpYXRlIFBBTiBjb29yZGluYXRv ci4gSW4gY2FzZSB0aGlzIGZsYWcgaXMgc2V0LCB0aGUgY29vcmRpbmF0b3INCmJyb2FkY2FzdHMg dGhlIG1lc3NhZ2Ugd2l0aGluIHRoZSBQQU4uIE90aGVyd2lzZSwgdGhlIG1lc3NhZ2UgaXMgZGly ZWN0ZWQgdG8NCnRoZSBjb29yZGluYXRvciBpdHNlbGYuDQoNClBsZWFzZSBsZXQgbWUga25vdyBp ZiBJJ20gdG90YWxseSB3cm9uZyBvciB0aGlzIG1heSBiZSBhbiBhcHByb2FjaC4NCg0KQmVzdCBy ZWdhcmRzLA0KRGF2aWQNCg0KDQotLS0tLVVyc3By/G5nbGljaGUgTmFjaHJpY2h0LS0tLS0NClZv bjogSWFuIENoYWtlcmVzIFttYWlsdG86aWFuLmNoYWtlcmVzQGdtYWlsLmNvbV0gDQpHZXNlbmRl dDogU29ubnRhZywgMjEuIE1haSAyMDA2IDE4OjAxDQpBbjogTWFyaW8gTWFvOyA2bG93cGFuQGll dGYub3JnDQpCZXRyZWZmOiBSZTogWzZsb3dwYW5dIENvbW1lbnRzIGFib3V0IHRoZSB1c2Ugb2Yg TXVsdGljYXN0IEFiaWxpdHkNCg0KSSB0aGluayB0aGF0IGEgcHJvdG9jb2wgbGlrZSBTTUYgKGRy YWZ0LWlldGYtbWFuZXQtc21mLTAyLnR4dCkgZm9yIG5vbi1ncm91cA0KYmFzZWQgc2ltcGxlIG11 bHRpY2FzdCB3b3VsZCBiZSBhcHByb3ByaWF0ZSBmb3IgNmxvd3Bhbi4gVGhlIFNNRiBkcmFmdCBk ZWFscw0KbWFpbmx5IHdpdGggZHVwbGljYXRlIHBhY2tldCBkZXRlY3Rpb24gKERQRCkuIFRob3Vn aCBpdCBzaG91bGQgYmUgdXNlZCBpbg0KY29uanVuY3Rpb24gd2l0aCBhbm90aGVyIGFsZ29yaXRo bSB0byBkZXRlcm1pbmUgYW4gb3B0aW1pemVkIHJlbGF5IHNldC4NCg0KVGhhdCBicmluZ3MgbWUg dG8gYW5vdGhlciBwb2ludCwgdG8gc3VwcG9ydCBtdXRsaWNhc3QgSSB0aGluayB0aGUgYWRhcHRh dGlvbg0KbGF5ZXIgc2hvdWxkIGhhdmUgYSBzZXF1ZW5jZSBudW1iZXIgZm9yIG11bHRpY2FzdCBw YWNrZXRzLg0KVGhpcyB3aWxsIGJlIHVzZWQgdG8gZGV0ZWN0IGR1cGxpY2F0ZSBwYWNrZXRzLiBT TUYgZGVmaW5lcyBhIElQdjYgaG9wIGJ5IGhvcA0Kb3B0aW9uIHRvIGFzc2lzdCBEUEQsIHRoaXMg ZmllbGQgc2hvdWxkIGJlIGludGVncmF0ZWQgaW50byB0aGUgc2hpbSBsYXllci4NCg0KSWFuIENo YWtlcmVzDQoNCk9uIDUvMjAvMDYsIE1hcmlvIE1hbyA8bWFyaW9tYW9AZ21haWwuY29tPiB3cm90 ZToNCj4NCj4NCj4gSGkgYWxsOg0KPiAgICAgVGhlcmUgaXMgc29tZSBjb21tZW50cyBhYm91dCBy ZWNlbnRseSBpbnRyb2R1Y2VkIE11bHRpY2FzdCBhYmlsaXR5Lg0KPg0KPiAgICAgSSBoYXZlIHJl YWQgRm9ybWF0LTAyIGRvY3VtZW50IGFuZCB0aGUgQ2Fyc3RlbidzIG1haWwgYWJvdXQgDQo+IGFk ZHJlc3NpbmcgbWFwIGZvciAxNi1iaXQgYWRkcmVzc2VzLiBJIHRoaW5rIGl0IGlzIGEgZ29vZCBz b2x1dGlvbiBmb3IgDQo+IHRoZSBhZGRyZXNzIGNvbmZ1c2lvbiBwcm9ibGVtLg0KPiBIb3dldmVy LCBsb29rcyBsaWtlIHRoZXJlIG5lZWRzIG90aGVyIHByZWNvbmRpdGlvbiB0byBtYWtlIE11bHRp Y2FzdCANCj4gd29yayBwcm9wZXJseSBhbmQgZWZmZWN0aXZlbHkgaW4gNkxvd1BBTi4NCj4NCj4g ICAgIEZpcnN0IGNvbmRpdGlvbiBpcyB0aGUgTUFDIGZpbHRlciwgYXMgSSBtZW50aW9uZWQgaW4g bGFzdCBtYWlsLCANCj4gSUVFRQ0KPiA4MDIuMTUuNA0KPiBNQUMgY2FuJ3QgZmxpdGVyIE11bHRp Y2FzdCBmcmFtZSwgIHRoZSByZWNlcHRpb24gYW5kIHJlamVjdGlvbiANCj4gYWxnb3JpdGhtIGFy ZSBkZXNjcmlwdGVkIGFzIGJlbGxvdyBpbiBzcGVjaWZpY2F0aW9uOg0KPiAtIElmIGEgZGVzdGlu YXRpb24gUEFOIGlkZW50aWZpZXIgaXMgaW5jbHVkZWQgaW4gdGhlIGZyYW1lLCBpdCBzaGFsbCAN Cj4gbWF0Y2ggbWFjUEFOSWQgb3Igc2hhbGwgYmUgdGhlIGJyb2FkY2FzdCBQQU4gaWRlbnRpZmll ciAoMCB4IGZmZmYpLg0KPiAtIElmIGEgc2hvcnQgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBpbmNs dWRlZCBpbiB0aGUgZnJhbWUsIGl0IHNoYWxsIA0KPiBtYXRjaCBlaXRoZXIgbWFjU2hvcnRBZGRy ZXNzIG9yIHRoZSBicm9hZGNhc3QgYWRkcmVzcyAoMCB4IGZmZmYpLiANCj4gT3RoZXJ3aXNlLCBp ZiBhbiBleHRlbmRlZCBkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIGluY2x1ZGVkIGluIHRoZSANCj4g ZnJhbWUsIGl0IHNoYWxsIG1hdGNoIGFFeHRlbmRlZEFkZHJlc3MuDQo+ICAgICBBY2NvcmRpbmcg dG8gdGhpcyBhbGdvcml0aG0sIHdoZW4gdGhlIE1BQyBsYXllciBvZiBzb21lIDgwMi4xNS40IA0K PiBub2RlIHJlY2VpdmUgYSBmcmFtZSB3aXRoIE11bHRpY2FzdCBkZXN0aW5hdGlvbiBhZGRyZXNz LCBob3cgd2lsbCBpdCANCj4ganVkZ2UgdGhlIGZyYW1lIHNob3VsZCBiZSBoYW5kbGVkIGJ1dCBu b3QgYmUgZGlzY2FyZGVkPyBGb3IgODAyLjE1LjQgDQo+IE1BQyBQSUIgY291bGQganVzdCBob2xk IG9uZSA2NC1iaXRzDQo+IEVVSS02NCBhZGRyZXNzIGFuZCBvbmUgMTYtYml0cyBzaG9ydCBhZGRy ZXNzKGZvciBub2RlJ3MgdW5pY2FzdCANCj4gYWRkcmVzcyksIG1heSBiZSB0aGUgb25seSB3YXkg dG8gZ2V0IE11bHRpY2FzdCBmcmFtZSBpcyB0byBzZXQgdGhlIE1BQyANCj4gc3VibGF5ZXIgdG8g cHJvbWlzY3VvdXMgbW9kZS4NCj4gQnkgZG9pbmcgdGhpcyBqb2IsIEFkYXB0YXRpb24gTGF5ZXIg Y291bGQgZ2V0IGFsbCBvZiBmcmFtZSBhcnJpdmVkIGluIA0KPiBNQUMgc3VibGF5ZXIgYW5kIGZp bHRlciB3aGF0IGl0IHdhbnQgYnkgaXRzZWxmLCBpbmNsdWRpbmcgTXVsdGljYXN0IA0KPiBmcmFt ZS4NCj4gICAgIFVuZm9ydHVuYXRlbHksIHRoZSBzb2x1dGlvbiBmb3IgdGhlIHByZXZpb3VzIHBy b2JsZW0gYWxzbyBjYXVzZSANCj4gYW5vdGhlciBwcm9ibGVtLg0KPiBUaGF0IGlzIGhvdyB0byBm b3dhcmQgdGhlIE11bHRpY2FzdCBmcmFtZSB0byByaWdodCBkZXN0aW5hdGlvbnMoZ3JvdXAgDQo+ IG1lbWJlcnMpLiBUaGUgZG9jdW1lbnQgIjZMb1dQQU4gTWVldGluZyA2NSBJRVRGIERhbGxhcyBG b3JtYXQgRG9jdW1lbnQgDQo+IGNoYW5nZXMiDQo+IG1lbnRpb25lZCBmb2xsb3dpbmcgcG9zc2li bGUgbWV0aG9kOiBkdW1iIGZsb29kaW5nLCBjb250cm9sbGVkIA0KPiBmbG9vZGluZyBhbmQgdW5p Y2FzdGluZyB0byB0aGUgUEFOIENPT1JESU5BVE9SLiBBcyBteSB1bmRlcnN0YW5kaW5nLCANCj4g YWxsIHRocmVlIGFib3ZlIHN0aWxsIG5lZWQNCj4gODAyLjE1LjQgTUFDIGJyb2FkY2FzdCBhbmQg QWRhcGF0YXRpb24gTGF5ZXIgYnJvYWRjYXN0IGZsb29kaW5nIHJlbGF5IA0KPiB0byBtYWtlIGFs bCBwb3NzaWJsZSByZWNlaXZlciBnZXQgTXVsdGljYXN0IGZyYW1lLiBUaGUgcmVxdWlyZW1lbnQg b2YgDQo+IEFkYXBhdGF0aW9uIExheWVyIGJyb2FkY2FzdCBmbG9vZGluZyByZWxheSBpcyBiZWNh dXNlIG5vdCBhbGwgb2YgDQo+IDgwMi4xNS40IG5vZGUgd2lsbCBiZSBpbiB0aGUgYnJvYWRjYXN0 IHJhbmdlIG9mIHRoZSBzZW5kZXIgaW4gTWVzaCANCj4gVG9wb2xvZ3ksIHVubGlrZSBpbiBFdGhl cm5ldC4gU28sIG1heWJlIHdlIHNob3VsZCBuZWVkIGFuIEFkYXB0YXRpb24gDQo+IE11bHRpY2Fz dCBSb3V0ZSBQb3RvY29sKGxpa2UgUElNLVNNIGluIEludGVybmV0KSB0byBidWlsZCBhIE11bHRp Y2FzdCANCj4gVHJlZSB3aGVuIHNvbWUgbm9kZSBqb2luIHNvbWUgTXVsdGljYXN0IGdyb3VwLiBB ZnRlciB0aGUgTXVsdGljYXN0IA0KPiB0cmVlIGhhcyBiZWVuIGJ1aWx0LCBub2RlIGluIHRoZSB0 cmVlIHdpbGwga25vdyB3aGVyZSBhcmUgdGhlIGdyb3VwIA0KPiBtZW1iZXJzIGluIGFuZCBob3cg dG8gZm9yd2FyZCBNdWx0aWNhc3QgZnJhbWUgdG8gdGhlbS4NCj4gICAgIEluIHRoZSBtYXR0ZXIg b2YgZmFjdCwgd2UgY291bGQgYWxzbyB1c2UgdGhlIHNwZWNpYWwgTXVsdGljYXN0IA0KPiBhZGRy ZXNzIGluIGEgbXVjaCBzaW1wbGUgd2F5LCB0aGF0IGlzIGp1c3QgbWFrZSBBZGFwdGF0aW9uIExh eWVyIGJlIGEgDQo+IE11bHRpY2FzdCBmcmFtZSBmaWx0ZXIuDQo+IEluIHRoaXMgd2F5LA0KPiBJ UHY2IExheWVyIHdpbGwgdGVsbCBBZGFwdGF0aW9uIExheWVyIHdoaWNoIE11bHRpY2FzdCBncm91 cCBpdCBoYXMgDQo+IGpvaW5lZCwgYW5kIEFkYXB0YXRpb24gTGF5ZXIgd2lsbCBkaXNjYXJkIHRo ZSBmcmFtZSBub3QgYmVsb25nIHRvIA0KPiB0aGVzZSBncm91cHMgYmVmb3JlIGhhbmRpbmcgaXQg dG8gSVAgTGF5ZXIuIEhvd2V2ZXIsIGlmIHdlIHdhbnQgdGhlIA0KPiBzZXBjaWFsIE11bHRpY2Fz dCBhZGRyZXNzIHJlYWxseSBkbyBzb21lIHdvcmssIGNvbnRyb2xsZWQgZm9yd2FyZGluZyANCj4g aW4gTXVsdGljYXN0IFRyZWUgbWF5IGJlIG5lY2Vzc2FyeS4gT3RoZXJ3aXNlLCBub2RlIHdpbGwg ZmlsbCANCj4gTXVsdGljYXN0IE1BQyBhZGRyZXNzIGluIEFkYXB0YXRpb24gb3IgTUFDIGhlYWRl ciBidXQgY291bGQgb25seSANCj4gYnJvYWRjYXN0IE11bHRpY2FzdCBmcmFtZSB0byBhbGwgdGhl IG5vZGUgaW4gdGhlIFBBTi4NCj4NCj4gICAgIEFjdHVhbGx5LCBJIHRoaW5rIDZMb3dQQU5lcnMg d2lsbCBmaW5kIGEgZ29vZCB3YXkgdG8gc29sdmUgdGhlIA0KPiBtdWx0aWNhc3QgcHJvYmxlbSBl dmVudHVhbGx5LiBCdXQgd2hhdCBJIHdhbnQgdG8gc2F5IGlzIGRvZXMgaXQgd29ydGg/IA0KPiBG b3IgODAyLjE1LjQgTUFDIGRvbid0IHN1cHBvcnQgbXVsdGljYXN0LCB3ZSBoYXZlIHRvIGRvIGFs bCB0aGUgd29yayANCj4gaW4gQWRhcHRhdGlvbiBMYXllci4gSW4gTG93UEFOIG5vZGUsIHJlc291 cmNlIGlzIGxpbWl0ZWQoZXhjZXB0IA0KPiBlbmVyZ3ksIG1lbW9yeSBmb3IgY29kZSBpcyB0aWdo dCBlaXRoZXIpLiBJZiB3ZSBtYWtlIHRoZSBwcm90b2NvbCBtb3JlIA0KPiBjb21wbGV4LCBtb3Jl IGNvZGUgc3BhY2Ugd2lsbCBiZSBuZWVkZWQuIFRha2UgdGhlIHBsYXRmb3JtIHdlIGFyZSANCj4g dXNpbmcgYXMgYW4gZXhhbXBsZSwgdGhlIEZyZWVzY2FsZSBNQzlTMDhHQjYwIE1DVSBoYXMgNjBL IEZsYXNoIGZvciANCj4gY29kZSwgaGFyZHdhcmUgZHJpdmVyIGFuZCA4MDIuMTUuNCBNQUMgbGli cmFyeShzdXBwbGllZCBieSBGcmVlc2NhbGUpIA0KPiB3aWxsIHRha2UgYXQgbGVhc3QgMzNLLCBj dXJyZW50IEFkYXB0YXRpb24gTGF5ZXIgd2lsbCB0YWtlIGFib3V0IA0KPiAxMksoaW5jbHVkaW5n IFJvdXRlIGFuZCBUb3BvbG9neSBNYWludGVuYW5jZSksIHRoaXMgbWVhbnMgb25seSAxNUsgaXMg DQo+IGxlZnQgZm9yIElQdjYsIE5EUCBhbmQgdXAtbGF5ZXIuIEZvciBvdXIgbGFiIGhhcyBpbXBs ZW1lbnRlZCBhbiANCj4gSVB2Ni9JUHY0IGR1YWwgcHJvdG9jb2wgc3RhY2sgaW4gQVJNIHBsYXRm b3JtIGJlZm9yZSwgd2UgY29uc2lkZXIgMTVLIA0KPiBjb2RlIHNwYWNlIGlzIHZlcnkgdGlnaHQg Zm9yIGEgcmVkdWNlZCBJUHY2IHN0YWNrLiBUaGUgcG9pbnQgaXMsIGlmIHdlIA0KPiBjb3VsZCBq dXN0IHVzZSBNQUMgYnJvYWRjYXN0IHRvIGxldCBJUCBNdWx0aWNhc3Qgd29yayB3ZWxsLCB3aHkg bm90IA0KPiBqdXN0IGRvIGl0PyBJZiB3ZSBhZGQgbW9yZSBhbmQgbW9yZSBmdW5jdGlvbiB0byBB ZGFwdGF0aW9uIExheWVyLCBJIA0KPiByZWFsbHkgd29ycnkgYWJvdXQgYSBsb3cgcG93ZXIgYW5k IGxvdyBjb3N0IGRldmljZSBoYXZpbmcgdGhlIGFiaWxpdHkgDQo+IHRvIHJ1biBpdC4NCj4NCj4g ICAgIFRoYW5rcy4NCj4NCj4gUmVnYXJkcywNCj4NCj4gTWFyaW8gTWFvDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IDZsb3dwYW4gbWFpbGluZyBs aXN0DQo+IDZsb3dwYW5AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vNmxvd3Bhbg0KPg0KPg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KNmxvd3BhbiBtYWlsaW5nIGxpc3QNCjZsb3dwYW5AaWV0Zi5v cmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4NCg== --===============1576101970== 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 --===============1576101970==-- From 6lowpan-bounces@ietf.org Fri Jun 09 18:29:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FopTx-0005QO-Mt; Fri, 09 Jun 2006 18:29:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FopTw-0005QE-MX for 6lowpan@ietf.org; Fri, 09 Jun 2006 18:29:32 -0400 Received: from mail-outbound.cso.atmel.com ([12.41.190.42] helo=csogate.cso.atmel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FopTo-0007XK-8x for 6lowpan@ietf.org; Fri, 09 Jun 2006 18:29:32 -0400 Received: from csomail.cso.atmel.com (csomail.cso.atmel.com [10.95.248.26]) by csogate.cso.atmel.com (8.13.6/8.13.6) with ESMTP id k59MSs3h023590; Fri, 9 Jun 2006 16:28:55 -0600 (MDT) Received: from [10.95.116.36] (eweddington.cso.atmel.com [10.95.116.36]) by csomail.cso.atmel.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0J0M00FNT6G5DW@csomail.cso.atmel.com>; Fri, 09 Jun 2006 16:28:53 -0600 (MDT) Date: Fri, 09 Jun 2006 16:28:54 -0600 From: Eric Weddington Subject: Re: [6lowpan] 6lowpan implementations In-reply-to: <1149580753.448535d18019e@wmail-mat.upc.es> To: Pere Salvatella Message-id: <4489F626.50501@cso.atmel.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) References: <1149580753.448535d18019e@wmail-mat.upc.es> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by csogate.cso.atmel.com id k59MSs3h023590 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: 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 Pere, Your group has done a very interesting approach. I would be very=20 interested in seeing your source code if you can make it available.=20 Also, what is the approximate time frame for release of your code? Gracias, Eric Weddington Pere Salvatella wrote: > Hi Karl, >=20 > Our group, Wireless Network Group of the Technical University of Catalo= nia, is=20 > currently working on a 6lowpan scheme over IEEE 802.15.4 networks, with= =20 > interest on the field of sensor networks. Our current work is based on = a minor=20 > implementation of IETF 6lowpan WG directives, an mainly hold on a base = of=20 > contributions from TinyOS community.=20 >=20 > The current implementation runs over TinyOS and it=92s been tested over= =20 > commercial TelosB research platform. The main IP stack is based on the=20 > adaptation made by HP Labs of the reduced uIP stack of SICS, but update= d to=20 > work on an Adhoc environment based on FFD (compared to HPLabs which bas= ed its=20 > facilities on a FFD acting as an access point for a network of RFD) and= to=20 > fulfill the points stated on the different drafts released. >=20 > Currently our implementation have: > - reduced IPv4 stack (mainly based on uIP of SICS) > - 6lowpan header (without header compression neither fragmented paquets= ) > - 6lowpan routing with DYMO and LOAD implementation > - Nowadays we are using short addresses inside the PAN. >=20 > We are working on: > - Add packet fragmentation and header compression > - adapting reduced IP stack to IPv6. > - Usage of IPv6 link addresses > - Add an autoconfiguration short address scheme based on 6lowpan direct= ives=20 >=20 > We haven=92t published yet any results neither code as opensource. Curr= ently we=20 > are debugging but we plan to release the code soon. If you are interest= ed on=20 > it, we can provide it to you. >=20 > Pere >=20 >=20 > Mensaje citado por Mayer Karl : >=20 >=20 >>Hi All, >> >>We have been investigating IP over 802.15.4 since some time and perform >>currently tests with IPv4 over 802.15.4 (using the uIP stack of SICS). >>The 6lowpan activities are very interesting for us and we are looking >>for public available code/implementations we can use for our >>investigations and tests. Since there is an 6lowpan testbed >>(www.6lowpan.org) there is obviously already code available but we are >>not sure whether it's open. So could anyone point me to available >>implementations/code? >> >>Thank you and best regards, >>Karl=20 >> >>--------------------------- >>Karl Mayer >>Technical Consultant >>IABG mbH >>Department for Information & Communication >>Einsteinstr. 20 >>85521 Ottobrunn >> >>Tel.: +49 89 6088 2066 >>Fax.: +49 89 6088 132066 >>E-mail: mayer@iabg.de >> >>_______________________________________________ >>6lowpan mailing list >>6lowpan@ietf.org >>https://www1.ietf.org/mailman/listinfo/6lowpan >> >=20 >=20 > ************************************************* > Pere Salvatella Renart > Wireless Networks Group=20 > Technical University of Catalonia (UPC). Spain=20 > peres@entel.upc.edu=20 >=20 >=20 >=20 > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan >=20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 12 06:04:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpjHe-0006I1-Qj; Mon, 12 Jun 2006 06:04:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpjHc-0006Hq-So for 6lowpan@ietf.org; Mon, 12 Jun 2006 06:04:32 -0400 Received: from brev.sics.se ([193.10.64.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpjHY-0004tj-Dm for 6lowpan@ietf.org; Mon, 12 Jun 2006 06:04:32 -0400 Received: from [193.10.65.93] (strumpa.sics.se [193.10.65.93]) by brev.sics.se (8.12.8/8.12.8) with ESMTP id k5CA4P7j015653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Mon, 12 Jun 2006 12:04:27 +0200 Message-ID: <448D3C1E.2060005@sics.se> Date: Mon, 12 Jun 2006 12:04:14 +0200 From: Adam Dunkels User-Agent: Thunderbird 1.5 (X11/20060225) MIME-Version: 1.0 To: 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [6lowpan] The uIP embedded TCP/IP stack 1.0 released 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 Hi, version 1.0 of the widely used uIP embedded TCP/IP stack is out: http://www.sics.se/~adam/uip/ This release adds rudimentary IPv6 support (TCP over IPv6 works, pingv6 works, neighbor solicitations are answered; tested only against FreeBSD 6.0 howver), as well as a number of other features and bugfixes. There is also a new mailing list for uIP users. Instructions on how to join the list is available from the uIP homepage. Best regards, /adam -- Adam Dunkels, Swedish Institute of Computer Science http://www.sics.se/~adam/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 12 20:40:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpwxT-0001QI-Ls; Mon, 12 Jun 2006 20:40:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpwxS-0001QC-M1 for 6lowpan@ietf.org; Mon, 12 Jun 2006 20:40:38 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpwxO-0004CM-VA for 6lowpan@ietf.org; Mon, 12 Jun 2006 20:40:38 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J0R00F9AWJK74@mailout1.samsung.com> for 6lowpan@ietf.org; Tue, 13 Jun 2006 09:40:32 +0900 (KST) Received: from daniellaptop ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0J0R007W9WJKFF@mmp2.samsung.com> for 6lowpan@ietf.org; Tue, 13 Jun 2006 09:40:32 +0900 (KST) Date: Tue, 13 Jun 2006 09:40:33 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] The uIP embedded TCP/IP stack 1.0 released To: Adam Dunkels , 6lowpan@ietf.org Message-id: <00fd01c68e81$fadde7d0$6dc6dba8@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 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: <448D3C1E.2060005@sics.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: 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 Hi Adam, Interesting news and good activities... Quick question; [1] 6lowpan basic solution as SubIP layer is embedded into the uIP stack ? [2] What you mean by the sentence below ? "neighbor solicitations are answered" It implies IPv6 ND Optimization or anything else ? Regards. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: "Adam Dunkels" To: <6lowpan@ietf.org> Sent: Monday, June 12, 2006 7:04 PM Subject: [6lowpan] The uIP embedded TCP/IP stack 1.0 released > Hi, > > version 1.0 of the widely used uIP embedded TCP/IP stack is out: > > http://www.sics.se/~adam/uip/ > > This release adds rudimentary IPv6 support (TCP over IPv6 works, pingv6 > works, neighbor solicitations are answered; tested only against FreeBSD > 6.0 howver), as well as a number of other features and bugfixes. There > is also a new mailing list for uIP users. Instructions on how to join > the list is available from the uIP homepage. > > Best regards, > > /adam > -- > Adam Dunkels, Swedish Institute of Computer Science > http://www.sics.se/~adam/ > > _______________________________________________ > 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 Tue Jun 13 04:57:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4hm-0003va-P7; Tue, 13 Jun 2006 04:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4hl-0003vO-69 for 6lowpan@ietf.org; Tue, 13 Jun 2006 04:56:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq3uK-0005al-80 for 6lowpan@ietf.org; Tue, 13 Jun 2006 04:05:52 -0400 Received: from brev.sics.se ([193.10.64.200]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fq3ia-0000bW-UL for 6lowpan@ietf.org; Tue, 13 Jun 2006 03:53:48 -0400 Received: from [193.10.65.93] (strumpa.sics.se [193.10.65.93]) by brev.sics.se (8.12.8/8.12.8) with ESMTP id k5D7rd7j002169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jun 2006 09:53:40 +0200 Message-ID: <448E6EF7.2000309@sics.se> Date: Tue, 13 Jun 2006 09:53:27 +0200 From: Adam Dunkels User-Agent: Thunderbird 1.5 (X11/20060225) MIME-Version: 1.0 To: Soohong Daniel Park Subject: Re: [6lowpan] The uIP embedded TCP/IP stack 1.0 released References: <448D3C1E.2060005@sics.se> <00fd01c68e81$fadde7d0$6dc6dba8@daniellaptop> In-Reply-To: <00fd01c68e81$fadde7d0$6dc6dba8@daniellaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.6 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 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 Hi! Soohong Daniel Park wrote: > [1] 6lowpan basic solution as SubIP layer is > embedded into the uIP stack ? No, uIP only includes the IP layer and above. > [2] What you mean by the sentence below ? > "neighbor solicitations are answered" > It implies IPv6 ND Optimization or anything else ? I basically mean that uIP only does the minimal ICMP processing needed to get communication working: it sends neighbor advertisement messages in response to incoming neighbor solicitation messages for the currently defined IP address (uIP only supports a single IP address for now). uIP does currently not even send neighbor solicitation messages for addresses that are not found in the neighbor list. So it is a very rudimentary IPv6 implementation in this respect. /adam -- Adam Dunkels, Swedish Institute of Computer Science http://www.sics.se/~adam/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 21 02:38:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FswMJ-0001go-M9; Wed, 21 Jun 2006 02:38:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FswMJ-0001fw-8o for 6lowpan@lists.ietf.org; Wed, 21 Jun 2006 02:38:39 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FswHc-0001lR-Vh for 6lowpan@lists.ietf.org; Wed, 21 Jun 2006 02:33:52 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J17003JQ69QNN@szxga01-in.huawei.com> for 6lowpan@lists.ietf.org; Wed, 21 Jun 2006 14:34:38 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1700CC269JVC@szxga01-in.huawei.com> for 6lowpan@lists.ietf.org; Wed, 21 Jun 2006 14:34:38 +0800 (CST) Received: from y52774 ([10.164.44.201]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1700L9F6OKY6@szxml04-in.huawei.com> for 6lowpan@lists.ietf.org; Wed, 21 Jun 2006 14:43:36 +0800 (CST) Date: Wed, 21 Jun 2006 14:32:48 +0800 From: Michael Ye Subject: [6lowpan]:draft-sarikaya-6lowpan-forwarding-00 To: 6lowpan@lists.ietf.org Message-id: <003f01c694fc$83687bd0$c92ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaU/IMqFJvEEgKwQ0i5TvCwWu3cUA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: bsarikaya@huawei.com 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 Hi Behcet , In section 4 of this draft, figure 2 is just a base architecture for 6lowpan forwarding. Where should 6lowpan protocol run in figure? thank you! BR, Michael _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jun 23 15:52:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtrhQ-0006sW-Qr; Fri, 23 Jun 2006 15:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtrfK-0002NK-Aq; Fri, 23 Jun 2006 15:50:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtrfK-0004xP-8e; Fri, 23 Jun 2006 15:50:06 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtrfG-0007WU-Sh; Fri, 23 Jun 2006 15:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5NJo2WR012302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtrfG-0003Bk-C9; Fri, 23 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 23 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: 6lowpan@lists.ietf.org Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-problem-03.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, G. Montenegro Filename : draft-ietf-6lowpan-problem-03.txt Pages : 14 Date : 2006-6-23 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. Additional goals may be found necessary over time and may be added to this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-03.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-03.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-03.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-6-23141726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6lowpan-problem-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6lowpan-problem-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-23141726.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 Sat Jun 24 03:59:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu338-000349-4P; Sat, 24 Jun 2006 03:59:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu337-000344-DI for 6lowpan@lists.ietf.org; Sat, 24 Jun 2006 03:59:25 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu335-0000vq-VN for 6lowpan@lists.ietf.org; Sat, 24 Jun 2006 03:59:25 -0400 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J1C00D2NU6XO7@mailout1.samsung.com> for 6lowpan@lists.ietf.org; Sat, 24 Jun 2006 16:59:21 +0900 (KST) Received: from daniellaptop ([124.235.139.1]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0J1C0007TU6WZ4@mmp1.samsung.com> for 6lowpan@lists.ietf.org; Sat, 24 Jun 2006 16:59:21 +0900 (KST) Date: Sat, 24 Jun 2006 16:59:25 +0900 From: Soohong Daniel Park To: 6lowpan <6lowpan@lists.ietf.org> Message-id: <002d01c69764$1cabc220$54a696dd@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [6lowpan] Fw: I-D ACTION:draft-daniel-6lowpan-security-analysis-01.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 FYI. >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPv6 over Low Power WPAN Security Analysis > Author(s) : S. Park, et al. > Filename : draft-daniel-6lowpan-security-analysis-01.txt > Pages : 11 > Date : 2006-6-23 > > This document discusses possible threats and security options for > IPv6-over-IEEE802.15.4 networks. It is an informational document to > raise awareness of security issues in IPv6 lowPan networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-security-analysis-01.txt > Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Jun 24 11:40:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuAFa-0005f7-EE; Sat, 24 Jun 2006 11:40:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuAFY-0005f1-E2 for 6lowpan@ietf.org; Sat, 24 Jun 2006 11:40:44 -0400 Received: from web81902.mail.mud.yahoo.com ([68.142.207.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FuAFX-0007UD-NL for 6lowpan@ietf.org; Sat, 24 Jun 2006 11:40:44 -0400 Received: (qmail 28601 invoked by uid 60001); 24 Jun 2006 15:40:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RpO5jL9IInUHbI5lMEZimS2OKyY6F6vYWhOcBEPveurdOJJjKMQ9N3nNVcRWXKX7YsOb8gi0mIqPI3KNrNm4XfaJskVjWdX9k2i9J8SM8Q3+wfpVK6hTEC4/Q+98MNIvBy7VeVRku111569Oh0BiwCRuoofqX2MEHaP6w68KTdc= ; Message-ID: <20060624154027.28599.qmail@web81902.mail.mud.yahoo.com> Received: from [200.21.190.118] by web81902.mail.mud.yahoo.com via HTTP; Sat, 24 Jun 2006 08:40:27 PDT Date: Sat, 24 Jun 2006 08:40:27 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] I-D ACTION:draft-ietf-6lowpan-problem-03.txt To: 6lowpan@ietf.org In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============1839841579==" Errors-To: 6lowpan-bounces@ietf.org --===============1839841579== Content-Type: multipart/alternative; boundary="0-1315632607-1151163627=:26418" --0-1315632607-1151163627=:26418 Content-Type: text/plain; charset=us-ascii I finally got around to making the changes based on the WG last call comments. Below, please find the changes based on an email from Christian. -gabriel ### Daniels nits ### I believe it is ready to the IESG. Good job Nandu and Gab...:-) Minor nits: both LoWPAN and 6LoWPAN seem a bit confused around the document. If available, defining terminology would be favorable. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ### End of Daniels nits ### gab> I clarified the usage for 6lowpan the first time it was used as follows: The following sections take into account these characteristics in describing the assumptions, problems statement and goals for LoWPANs, and, in particular, for 6LoWPANs (IPv6-based LoWPAN networks). I also went through the document to make sure it was consistent in its usage. ### My nits ### Sorry for the late feedback. As Daniel said, good job Nandu and Gab. However, I have the following nitpicks: Section: 2. Overview Possibly missing a linespace between bullet 9. and 10. gab> Ok. Section: 4.2. Topologies Last sentence in this section: "This, or course..." should probably be "This, of course" gab> Ok. Section: 4.4. Limited configuration and management Last sentence in this section: "...yet be powerful to control dense..." I suggest maybe to add "enough" between "powerful" and "to". gab> ok. Section: 4.6. Security Last sentence in this section: "Please refer to security consideration section below for an in depth requirements for security" I suggest change to: "Please refer to the security considerations section below for in depth security requirements." gab> ok. Section: 5. Goals (Page 7-8): I think the reader would gain a better understanding of the goals for 6lowpan if we start each goal with a clear definition (one-sentence) of the goal, then followed by the related background information. The goals appear more or less hidden in the text in its current form. This is especially true for goal nr. 2, which is mostly background information until at the end it is stated "this goal needs to investigate using existing header compression... ". gab> Good suggestion, added topic headers. I also think the usage of word goal in goals 2 and 3 are confusing. Examples: "...this goal needs to investigate..." (Goal nr. 2) "The goal should specify a method..." (Goal nr. 3) It is we (the working group) not the goal , which needs to investigate and to specify. Correct me, if I'm reading it wrong. gab> Yes, clumsy wording, I revised it, thanks. Overall I think the document is good, and I believe if you incorporate my nits on the goals section, then it is IESG ready. Again, excellent work. :-) gab> Thanks for your generous comments. As you point out the wording needed some work, so I gave it another editorial pass to try to improve it. Hope it helps. Regards Christian ### End of my nits ### ----- Original Message ---- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: 6lowpan@lists.ietf.org Sent: Friday, June 23, 2006 12:50:02 PM Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-problem-03.txt 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, G. Montenegro Filename : draft-ietf-6lowpan-problem-03.txt Pages : 14 Date : 2006-6-23 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. Additional goals may be found necessary over time and may be added to this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-03.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-03.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-03.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. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-1315632607-1151163627=:26418 Content-Type: text/html; charset=us-ascii
I finally got around to making the changes based on the WG last call comments.

Below, please find the changes based on an email from Christian.

-gabriel

### Daniels nits ###

I believe it is ready to the IESG. Good job Nandu and Gab...:-)

Minor nits: both LoWPAN and 6LoWPAN seem a bit confused
around the document. If available, defining terminology would
be favorable.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

### End of Daniels nits ###

gab> I clarified the usage for 6lowpan the first time it was used as
follows:

    The following sections take into account these characteristics
    in describing the  assumptions, problems statement and
    goals for LoWPANs, and, in particular, for 6LoWPANs (IPv6-based
    LoWPAN networks).

I also went through the document to make sure it was consistent in its
usage.

### My nits ###

Sorry for the late feedback.

As Daniel said, good job Nandu and Gab.

However, I have the following nitpicks:

Section: 2. Overview
Possibly missing a linespace between bullet 9. and 10.

gab> Ok.

Section: 4.2. Topologies
Last sentence in this section:
 "This, or course..."
should probably be
 "This, of course"

gab> Ok.

Section: 4.4. Limited configuration and management
Last sentence in this section:
 "...yet be powerful to control dense..."
I suggest maybe to add "enough" between "powerful" and "to".

gab> ok.

Section: 4.6. Security
Last sentence in this section:
 "Please refer to security consideration section below for an in depth
requirements for security"
I suggest change to:
 "Please refer to the security considerations section below
   for in depth security requirements."

gab> ok.

Section: 5. Goals (Page 7-8):

I think the reader would gain a better understanding of the goals for
6lowpan if we start each goal with a clear definition (one-sentence) of
the goal, then followed by the related background information. The goals
appear more or less hidden in the text in its current form. This is
especially true for goal nr. 2, which is mostly background information
until at the end it is stated "this goal needs to investigate using
existing header compression... ".

gab> Good suggestion, added topic headers.

I also think the usage of word goal in goals 2 and 3 are confusing.
Examples:
"...this goal needs to investigate..." (Goal nr. 2)
"The goal should specify a method..." (Goal nr. 3)
It is we (the working group) not the goal , which needs to investigate
and to specify. Correct me, if I'm reading it wrong.

gab> Yes, clumsy wording, I revised it, thanks.

Overall I think the document is good, and I believe if you incorporate
my nits on the goals section, then it is IESG ready.

Again, excellent work. :-)

gab> Thanks for your generous comments. As you point out the wording
needed some work, so I gave it another editorial pass to try
to improve it. Hope it helps.



Regards
Christian

### End of my nits ###


----- Original Message ----
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: 6lowpan@lists.ietf.org
Sent: Friday, June 23, 2006 12:50:02 PM
Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-problem-03.txt

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, G. Montenegro
    Filename    : draft-ietf-6lowpan-problem-03.txt
    Pages        : 14
    Date        : 2006-6-23
    
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.  Additional
   goals may be found necessary over time and may be added to this
   document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-03.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-03.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-03.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.
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--0-1315632607-1151163627=:26418-- --===============1839841579== 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 --===============1839841579==-- From 6lowpan-bounces@ietf.org Sat Jun 24 12:03:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuAbJ-00039V-Ct; Sat, 24 Jun 2006 12:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuAbI-00036M-8j for 6lowpan@ietf.org; Sat, 24 Jun 2006 12:03:12 -0400 Received: from web81914.mail.mud.yahoo.com ([68.142.207.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FuAbH-0001a8-Ph for 6lowpan@ietf.org; Sat, 24 Jun 2006 12:03:12 -0400 Received: (qmail 64354 invoked by uid 60001); 24 Jun 2006 16:03:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Ab/9Fw27N3iYTB/mQfpNRQnGGnQeAfMTqSRyXcZMk8jLhCyveeG0CvB5LCHsV6/1iPpsqxgJUanf5A1eYFuB+4mjXM+Q+71g3K8h9A+gI908nmsZGeE0wFPzF12Wv9ojxVsXnUtDWoHb181KD9SAZD+W9mdFUKw3yo8GAgcrQHs= ; Message-ID: <20060624160311.64352.qmail@web81914.mail.mud.yahoo.com> Received: from [200.21.190.118] by web81914.mail.mud.yahoo.com via HTTP; Sat, 24 Jun 2006 09:03:11 PDT Date: Sat, 24 Jun 2006 09:03:11 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] 6lowpan 16-bit address space map To: Carsten Bormann , 6lowpan@ietf.org In-Reply-To: <622F0374-9E10-4822-ABFD-9E28FCBEC72C@tzi.org> MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Carsten Bormann X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============0173943996==" Errors-To: 6lowpan-bounces@ietf.org --===============0173943996== Content-Type: multipart/alternative; boundary="0-1485358897-1151164991=:62960" --0-1485358897-1151164991=:62960 Content-Type: text/plain; charset=us-ascii I've added a much simpler version, only mentioning those fields we are specifying in the document. Anything not currently specified can be defined later, right now the important thing is to reserve the relevant space. I include below the IANA section on 16-bit address format, as it currently looks. -gabriel ps - currently on vacation and with spotty email connectivity, but I'll be submitting this before the deadline. This document creates a new IANA registry for the 16-bit short address fields used in 6LoWPAN packets. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16-bit short Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 These address fields MUST follow this format (referring to bit fields in the order from 0 to 7): O: The first bit SHALL be zero if the 16-bit address is a non- multicast (e.g., unicast) address. This leaves 15 bits for the actual address. 100: Bits 0,1 and 2 SHALL follow this pattern if the 16-bit address is a multicast address. This leaves 13 bits for the actual multicast address. 101, 110 or 111: These patterns for bits 0,1 and 2 are reserved. for future assignment as per the policy mentioned above. ----- Original Message ---- From: Carsten Bormann To: 6lowpan@ietf.org Cc: Carsten Bormann Sent: Friday, April 21, 2006 11:40:52 AM Subject: [6lowpan] 6lowpan 16-bit address space map Lowpanners, here is a more detailed idea of how the addressing map for 16-bit addresses could look like. Comments welcome. 0xxxxxxxxxxxxxxx unicast addresses allocated by the PAN coordinator 100xxxxxxxxxxxxx special unicast addresses, e.g. 1000000000000000 PAN coordinator 1000000000000001 backup PAN coordinator (just making this up now) allocation requires standards action 101xxxxxxxxxxxxx reserved (allocation requires standards action) 110xxxxxxxxxxxxx multicast addresses (mapping per format document) 111xxxxxxxxxxxxx special addresses, often multicast, e.g. 1111111111111110 (the 0xfffe thing from 802.15.4) 1111111111111111 radio-range-limited localcast to non-sleepers allocation requires standards action I'm not so sure about using 100xxxxxxxxxxxxx for the PAN coordinator things etc; maybe we should use 111xxxxxxxxxxxxx for all "special" addresses to have more contiguous space reserved for future use. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-1485358897-1151164991=:62960 Content-Type: text/html; charset=us-ascii
I've added a much simpler version, only mentioning those fields we are specifying in the document.
Anything not currently specified can be defined later, right now the important thing is to reserve the
relevant space.

I include below the IANA section on 16-bit address format, as it currently looks.

-gabriel
ps - currently on vacation and with spotty email connectivity, but I'll be submitting this before the deadline.
   This document creates a new IANA registry for the 16-bit short
   address fields used in 6LoWPAN packets.

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          
            |     16-bit short Address      |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 11

   These address fields MUST follow this format (referring to bit fields
   in the order from 0 to 7):

   O: The first bit SHALL be zero if the 16-bit address is a non-
      multicast (e.g., unicast) address.  This leaves 15 bits for the
      actual address.

   100: Bits 0,1 and 2 SHALL follow this pattern if the 16-bit address
      is a multicast address.  This leaves 13 bits for the actual
      multicast address.

   101, 110 or 111: These patterns for bits 0,1 and 2 are reserved. for
      future assignment as per the policy mentioned above.


----- Original Message ----
From: Carsten Bormann <cabo@tzi.org>
To: 6lowpan@ietf.org
Cc: Carsten Bormann <cabo@tzi.org>
Sent: Friday, April 21, 2006 11:40:52 AM
Subject: [6lowpan] 6lowpan 16-bit address space map

Lowpanners,

here is a more detailed idea of how the addressing map for 16-bit
addresses could look like.  Comments welcome.

0xxxxxxxxxxxxxxx unicast addresses allocated by the PAN coordinator
100xxxxxxxxxxxxx special unicast addresses, e.g.
      1000000000000000 PAN coordinator
      1000000000000001 backup PAN coordinator (just making this up now)
      allocation requires standards action
101xxxxxxxxxxxxx reserved (allocation requires standards action)
110xxxxxxxxxxxxx multicast addresses (mapping per format document)
111xxxxxxxxxxxxx special addresses, often multicast, e.g.
      1111111111111110 (the 0xfffe thing from 802.15.4)
      1111111111111111 radio-range-limited localcast to non-sleepers
      allocation requires standards action

I'm not so sure about using 100xxxxxxxxxxxxx for the PAN coordinator
things etc; maybe we should use 111xxxxxxxxxxxxx for all "special"
addresses to have more contiguous space reserved for future use.

Gruesse, Carsten


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--0-1485358897-1151164991=:62960-- --===============0173943996== 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 --===============0173943996==-- From 6lowpan-bounces@ietf.org Sat Jun 24 12:26:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuAxv-0004Wm-Ul; Sat, 24 Jun 2006 12:26:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuAxu-0004Qe-MA for 6lowpan@ietf.org; Sat, 24 Jun 2006 12:26:34 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuAxt-00052F-7h for 6lowpan@ietf.org; Sat, 24 Jun 2006 12:26:34 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 63B478E0002; Sat, 24 Jun 2006 18:26:26 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jun 2006 18:26:26 +0200 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jun 2006 18:25:29 +0200 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jun 2006 11:25:03 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [6lowpan] Fw: I-DACTION:draft-daniel-6lowpan-security-analysis-01.txt Date: Sat, 24 Jun 2006 12:25:02 -0400 Message-ID: <95D8C1105D54EB41864F8831E6C4EB7513FD72@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fw: I-DACTION:draft-daniel-6lowpan-security-analysis-01.txt Thread-Index: AcaXqr2sb/pW269kR+qAeLGqu8Cz3A== From: "Wassim Haddad \(KI/EAB\)" To: X-OriginalArrivalTime: 24 Jun 2006 16:25:03.0870 (UTC) FILETIME=[BF7099E0:01C697AA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 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 Hi Daniel, You may be interested in taking a look to the ongoing work on Optimizing the SEND protocol: draft-haddad-mipshop-optisend-01 Regards, Wassim H. >A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories.=20 > =20 > Title : IPv6 over Low Power WPAN Security Analysis=20 > Author(s) : S. Park, et al.=20 > >Daniel (Soohong Daniel Park)=20 >Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Jun 24 12:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBKh-00036b-LV; Sat, 24 Jun 2006 12:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBKg-00035Z-H0 for 6lowpan@ietf.org; Sat, 24 Jun 2006 12:50:06 -0400 Received: from web81904.mail.mud.yahoo.com ([68.142.207.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FuBKf-0007AD-Uy for 6lowpan@ietf.org; Sat, 24 Jun 2006 12:50:06 -0400 Received: (qmail 71227 invoked by uid 60001); 24 Jun 2006 16:50:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RbqXBR8T3N+LQXfKgZ/0eG5DZos0JD6wm40O+GEaGva+chwoNT5clSbDUSCyHJJ1DOMiMOkdVXUL1E3nk/Wx9ONjWqY13kL9Wk2etbshMd/d9J+IWMgSdMF8r8biEuz29egSjHpnf24eJP2W+X8L38UMGczwtWIlACnb+iWBurc= ; Message-ID: <20060624165005.71225.qmail@web81904.mail.mud.yahoo.com> Received: from [200.21.190.118] by web81904.mail.mud.yahoo.com via HTTP; Sat, 24 Jun 2006 09:50:05 PDT Date: Sat, 24 Jun 2006 09:50:05 -0700 (PDT) From: gabriel montenegro To: Samita Chakrabarti , 6lowpan@ietf.org In-Reply-To: <43b91d370604281745j765a191bp22843d890af5eab9@mail.gmail.com> MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Subject: [6lowpan] Re: Comments on the Format-02 document X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============1202441649==" Errors-To: 6lowpan-bounces@ietf.org --===============1202441649== Content-Type: multipart/alternative; boundary="0-1357031563-1151167805=:70216" --0-1357031563-1151167805=:70216 Content-Type: text/plain; charset=us-ascii inline... ----- Original Message ---- From: Samita Chakrabarti To: gabriel montenegro ; 6lowpan@ietf.org Sent: Friday, April 28, 2006 5:45:12 PM Subject: Comments on the Format-02 document Hello Gabriel: Here are some comments on the latest version of the format document. Hope they are not too late. Thanks, -Samita Nits: Typo in Introduction: Likewise, the provisions required for packet delivery in IEEE 802.15.4 meshes defined. Section 2. gab> reworded slightly "As usual, hosts learn IPv6 prefixes via router advertisements ([I-D.ietf-ipv6-2461bis])." Does it make sense to mention about ND for lowpan work in this context as well ? gab> just mentioned that the WG may be pursuing more work here. Section 4 ( Reassembly): Each fragment contains "datagram_size" and datagram_tag and offset. Should "datagram_size" be replaced by "fragment_size" for the fragmented packets ? Is there anyway, during re-assembly one would know about the fragment payload size ? Note that the offset and datagram_size do not provide the info on the current fragment size. gab> I left it as datagram_size, because that is what it means: the size of the entire IP layer datagram. The size of this particular fragment can be inferred from the PPDU information (the "Frame Length" field in the PHY 802.15.4 packet). Section 7. Please have a subheading for defining the IPv6 SLLA, TLLA option formats. On the first look, it is a bit confusing as it seems IPv6 unicast address mapping from the 802.15.4 short and long addresses. gab> Left it as is, since this is exactly the same thing that the IP over ethernet spec (rfc 2464) says. SLLA/TLLA is already mentioned as in that document: The Source/Target Link-layer Address option has the following forms when the link layer is IEEE 802.15.4 and the addresses are EUI-64 or 16-bit short addresses, respectively. Section 8. Please clarify that multicast 802.15.4 address is 16bit address. Q: Can IETF specify such L2 addressing and specification ? Is there any plan on IEEE to accomodate this feature? gab> done. dunno about IEEE. I don't expect they're doing this, as this is done here to map IPv6 multicast addresses specifically. Notice that this support is optional in our format document, as the full specification is not to be done here, but in other document. The rest looks ok to me. The header compression part is a bit tricky and complex. Should this draft suggest a default header compression scheme for a suggestion to the implementors? gab> Dunno, I think there is text already very strongly suggesting this be supported (otherwise IPv6 is not practical). thanks, -gabriel --0-1357031563-1151167805=:70216 Content-Type: text/html; charset=us-ascii
inline...

----- Original Message ----
From: Samita Chakrabarti <samitac2@gmail.com>
To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>; 6lowpan@ietf.org
Sent: Friday, April 28, 2006 5:45:12 PM
Subject: Comments on the Format-02 document

Hello Gabriel:
 
Here are some comments on the latest version of the format document.
Hope they are not too late.
 
Thanks,
-Samita
 

Nits:

Typo in Introduction:

Likewise, the provisions required for packet delivery in IEEE 802.15.4 meshes  <is> defined.

Section 2.



gab> reworded slightly

"As usual, hosts learn IPv6 prefixes via router advertisements ([I-D.ietf-ipv6-2461bis])."

Does it make sense to mention about ND for lowpan work in this context as well ?

 

gab> just mentioned that the WG may be pursuing more work here.


Section 4 ( Reassembly):

Each fragment contains "datagram_size" and datagram_tag and offset.

Should "datagram_size" be replaced by "fragment_size" for the fragmented

packets ? Is there anyway, during re-assembly one would know about the

fragment payload size ? Note that the offset and datagram_size do not

provide the info on the current fragment size.

 

gab> I left it as datagram_size, because that is what it means: the size of the

entire IP layer datagram. The size of this particular fragment can be inferred

from the PPDU information (the "Frame Length" field in the PHY 802.15.4

packet).


Section 7.

Please have a subheading for defining the IPv6 SLLA, TLLA option formats.

On the first look, it is a bit confusing as it seems IPv6 unicast address

mapping from the 802.15.4 short and long addresses.



gab> Left it as is, since this is exactly the same thing that the IP over ethernet

spec (rfc 2464) says. SLLA/TLLA is already mentioned as in that document:



   The Source/Target Link-layer Address option has the following forms
   when the link layer is IEEE 802.15.4 and the addresses are EUI-64 or


   16-bit short addresses, respectively.

Section 8.

Please clarify that multicast 802.15.4 address is 16bit address.

Q: Can IETF specify such L2 addressing and specification ? Is there

any plan on IEEE to accomodate this feature?



gab> done. dunno about IEEE. I don't expect they're doing this, as this is done here

to map IPv6 multicast addresses specifically. Notice that this support is optional

in our format document, as the full specification is not to be done here, but in other

document.

 

The rest looks ok to me. The header compression part is a bit tricky

and complex. Should this draft suggest a default header compression

scheme for a suggestion to the implementors?



gab> Dunno, I think there is text already very strongly suggesting this be supported

(otherwise IPv6 is not practical).



thanks,

-gabriel
--0-1357031563-1151167805=:70216-- --===============1202441649== 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 --===============1202441649==-- From 6lowpan-bounces@ietf.org Sat Jun 24 13:13:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBhj-0004A4-Sy; Sat, 24 Jun 2006 13:13:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBhi-000467-Tx for 6lowpan@lists.ietf.org; Sat, 24 Jun 2006 13:13:54 -0400 Received: from web81906.mail.mud.yahoo.com ([68.142.207.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FuBhh-0001fC-Hl for 6lowpan@lists.ietf.org; Sat, 24 Jun 2006 13:13:54 -0400 Received: (qmail 10582 invoked by uid 60001); 24 Jun 2006 17:13:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=rg9SsloY0KDZaZJiDd9OlaK+v6mcE6GMmHW83e/5RsdcGyxVuYO+tIa/JfZLKr/hdFMJxQ/ScpEALda9I4dQiVJ+xghTDFnEnpdGAuh39MCFiM4KTTnE9IlgZndamdFJAtRT08ALKil5v8A1+lr9u0XlVOCbgWrL2HfhrgXgkMg= ; Message-ID: <20060624171352.10580.qmail@web81906.mail.mud.yahoo.com> Received: from [200.21.190.118] by web81906.mail.mud.yahoo.com via HTTP; Sat, 24 Jun 2006 10:13:52 PDT Date: Sat, 24 Jun 2006 10:13:52 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Couple of questions from packet format document To: Soohong Daniel Park , 6lowpan <6lowpan@lists.ietf.org> In-Reply-To: <024f01c65dfb$62650580$6dc6dba8@daniellaptop> MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============0583192847==" Errors-To: 6lowpan-bounces@ietf.org --===============0583192847== Content-Type: multipart/alternative; boundary="0-956021258-1151169232=:10346" --0-956021258-1151169232=:10346 Content-Type: text/plain; charset=us-ascii inline... ----- Original Message ---- From: Soohong Daniel Park To: 6lowpan <6lowpan@lists.ietf.org> Sent: Tuesday, April 11, 2006 11:36:09 PM Subject: [6lowpan] Couple of questions from packet format document Gabriel - While going through our packet format document, a couple of questions happen in my side...Please clarify them. [1] In section 9.1, this document says " the packet length can be inferred from the layer two"... I am not sure how it can be inferred from the layer two. gab> good catch. Reworded as follows: ...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), [2] In section 9.2, UDP source/destination port is obtained by calculating: P + short_port value. P is a predetermined port number with value TBD. The short_port is expressed as a 4-bit value which is carried "in-line" (Section 9.3.2). I am not sure what you mean by short_port. I can't see any relevant mention in Section 9.3.2. gab> They just go inline as indicated in that section. The only difference is that instead of taking 16 bits they take 4 bits. Added this to clarify: If either the source or destination ports are in "short_port" notation (as indicated in the compressed UDP header), then instead of taking 16 bits, the inline port numbers take 4 bits. gab> I also added the IANA section to ask for assignment of this port number P for use with short_port notation. PS, just curious whether we should consider IPv6 extension from the Next Header perspective. gab> not sure what you mean here. perhaps something you can bring up during WG last call. Thanks, Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-956021258-1151169232=:10346 Content-Type: text/html; charset=us-ascii
inline...

----- Original Message ----
From: Soohong Daniel Park <soohong.park@samsung.com>
To: 6lowpan <6lowpan@lists.ietf.org>
Sent: Tuesday, April 11, 2006 11:36:09 PM
Subject: [6lowpan] Couple of questions from packet format document

Gabriel - While going through our packet format document,
a couple of questions happen in my side...Please clarify them.

[1] In section 9.1, this document says " the packet length
can be inferred from the layer two"...

I am not sure how it can be inferred from the layer two.

gab> good catch. Reworded as follows:
     ...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),

[2] In section 9.2, UDP source/destination port is obtained
by calculating: P + short_port value. P is a predetermined
port number with value TBD. The short_port is expressed
as a 4-bit value which is carried "in-line" (Section 9.3.2).

I am not sure what you mean by short_port. I can't
see any relevant mention in Section 9.3.2.

gab> They just go inline as indicated in that section. The only difference is that instead of
taking 16 bits they take 4 bits. Added this to clarify:

    If either the
    source or destination ports are in "short_port" notation (as indicated
    in the compressed UDP header), then instead of taking 16 bits, the inline
    port numbers take 4 bits.

gab> I also added the IANA section to ask for assignment of this port number P for use
with short_port notation.

PS, just curious whether we should consider IPv6
extension from the Next Header perspective.

gab> not sure what you mean here. perhaps something you can bring up during WG last call.

Thanks,

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--0-956021258-1151169232=:10346-- --===============0583192847== 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 --===============0583192847==-- From 6lowpan-bounces@ietf.org Sat Jun 24 13:18:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBly-00055D-86; Sat, 24 Jun 2006 13:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBlw-000557-Og for 6lowpan@lists.ietf.org; Sat, 24 Jun 2006 13:18:16 -0400 Received: from web81904.mail.mud.yahoo.com ([68.142.207.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FuBlt-0001xR-D8 for 6lowpan@lists.ietf.org; Sat, 24 Jun 2006 13:18:16 -0400 Received: (qmail 81435 invoked by uid 60001); 24 Jun 2006 17:18:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=vpnkhG27TSPCamWfviZU00RL8IO9b4RoiSyN73qokK+TPv62UVis5rTlYrZ2CWOc6JF5nWdtrFQd6XhWVoVJxkPr4AdB2EmmnhPeOTt/8cAnplxV93v6ovVFCo5+BagKzK+LqynE+utgZYyRnyB+tkvAOADBtEJUtfrAp4EAhbY= ; Message-ID: <20060624171813.81433.qmail@web81904.mail.mud.yahoo.com> Received: from [200.21.190.118] by web81904.mail.mud.yahoo.com via HTTP; Sat, 24 Jun 2006 10:18:13 PDT Date: Sat, 24 Jun 2006 10:18:13 -0700 (PDT) From: gabriel montenegro To: Ki-Hyung Kim , 6lowpan <6lowpan@lists.ietf.org> In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [6lowpan] Re: Comment on the format document for IPv6-multicast support X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============0713176876==" Errors-To: 6lowpan-bounces@ietf.org --===============0713176876== Content-Type: multipart/alternative; boundary="0-1648130675-1151169493=:81430" --0-1648130675-1151169493=:81430 Content-Type: text/plain; charset=us-ascii I think the full specification for multicast is probably something that belongs in its own specification, and may depend on your choice of mesh routing protocol. Your question as to how suitable is the current format is something that Ian Chakeres has discussed in a message of his. I think that the current format may not be suitable, because it lacks a field to help eliminate duplicates. -gabriel ----- Original Message ---- From: Ki-Hyung Kim To: 6lowpan <6lowpan@lists.ietf.org> Cc: gabriel montenegro Sent: Sunday, April 30, 2006 11:14:52 AM Subject: Comment on the format document for IPv6-multicast support Hi Gabriel and 6lowpaners, I want to raise an issue of supporting IPv6-multicast in 6lowpan. There are some cases which might require multicasting in 6lowpan such as packet transmission with multicast targets (0xFF~), Neighbor or Router advertisements. We can optimize some multicast by using an optimization technique, e.g. ND optimization, but not for all cases such as multicast targets(0xFF). Because the link layer of 6lowpan does not support multicast, multicast should be realized by broadcast (or flooding). My question is whether the current format document does support the broadcasting(or flooding) or not. It is clear that broadcast ID should exist on the adaptation layer for supporting broadcasting(or flooding) at the adaptation layer. ( in order to avoid duplicate handling of the same broadcast messages on a node) Is there a mechanism of broadcast ID in the current format document? If the adaptation layer does not have the mechanism, I believe that we should include it. What is your opinions? -- Ki-Hyung Kim Associate Professor Division of Information and Computer Eng., Ajou University, Suwon, Korea 442-749 Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 http://www.6lowpan.org --0-1648130675-1151169493=:81430 Content-Type: text/html; charset=us-ascii
I think the full specification for multicast is probably something that belongs in its own specification, and may
depend on your choice of mesh routing protocol. Your question as to how suitable is the current format is
something that Ian Chakeres has discussed in a message of his. I think that the current format may not
be suitable, because it lacks a field to help eliminate duplicates.

-gabriel

----- Original Message ----
From: Ki-Hyung Kim <kkim86@gmail.com>
To: 6lowpan <6lowpan@lists.ietf.org>
Cc: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Sent: Sunday, April 30, 2006 11:14:52 AM
Subject: Comment on the format document for IPv6-multicast support

Hi Gabriel and 6lowpaners,
 
I want to raise an issue of supporting IPv6-multicast in 6lowpan.
 
There are some cases which might require multicasting in 6lowpan such as packet transmission with multicast targets (0xFF~), Neighbor or Router advertisements.
We can optimize some multicast by using an optimization technique, e.g. ND optimization, but not for all cases such as multicast targets(0xFF).
Because the link layer of 6lowpan does not support multicast, multicast should be realized by broadcast (or flooding).
 
My question is whether the current format document does support the broadcasting(or flooding) or not.
It is clear that broadcast ID should exist on the adaptation layer for supporting broadcasting(or flooding) at the adaptation layer. ( in order to avoid duplicate handling of the same broadcast messages on a node)
Is there a mechanism of broadcast ID in the current format document? If the adaptation layer does not have the mechanism, I believe that we should include it.
 
What is your opinions?
 

--
Ki-Hyung Kim
Associate Professor
Division of Information and Computer Eng., Ajou University, Suwon, Korea 442-749
Tel: +82-31-219-2433, Cel: +82-17-760-2551,  Fax: +82-31-219-2433 http://www.6lowpan.org

--0-1648130675-1151169493=:81430-- --===============0713176876== 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 --===============0713176876==-- From 6lowpan-bounces@ietf.org Sat Jun 24 13:20:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBnn-00060a-Sm; Sat, 24 Jun 2006 13:20:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBnm-00060P-G9 for 6lowpan@ietf.org; Sat, 24 Jun 2006 13:20:10 -0400 Received: from web81902.mail.mud.yahoo.com ([68.142.207.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FuBnl-00028W-SU for 6lowpan@ietf.org; Sat, 24 Jun 2006 13:20:10 -0400 Received: (qmail 66391 invoked by uid 60001); 24 Jun 2006 17:20:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=hl9Ievj6nYDO7cSmKwlfCKb9lt3yDACMtrKlUWkSjo8Dr8uxO+qLR35+VD5w08p5C/C0dcKvUtgcG7/ODuq/IFvCbvFOFoQKGJd16x00g0r9hVZo3IHDelOnl4nc+rTqD6908NpEgQIQs4Ca1pOfcFwAfLWkTcg6+JMi25PYVuA= ; Message-ID: <20060624172004.66389.qmail@web81902.mail.mud.yahoo.com> Received: from [200.21.190.118] by web81902.mail.mud.yahoo.com via HTTP; Sat, 24 Jun 2006 10:20:04 PDT Date: Sat, 24 Jun 2006 10:20:04 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Comments about the use of Multicast Ability To: Mario Mao , 6lowpan@ietf.org In-Reply-To: <001d01c67c02$2d238840$7fc0a8c0@netlab.cs.ecnu.edu.cn> MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============1399818539==" Errors-To: 6lowpan-bounces@ietf.org --===============1399818539== Content-Type: multipart/alternative; boundary="0-1825192179-1151169604=:65772" --0-1825192179-1151169604=:65772 Content-Type: text/plain; charset=us-ascii I also have strong misgivings about adding more functionality like this and look to folks implementing this (like yourselves) to provide feedback on how practical this all is. At any rate, the current spec is clear that the multicast support is optional (it is, after all, an optimization). -gabriel ----- Original Message ---- From: Mario Mao To: 6lowpan@ietf.org Sent: Saturday, May 20, 2006 4:40:16 AM Subject: [6lowpan] Comments about the use of Multicast Ability Hi all: There is some comments about recently introduced Multicast ability. I have read Format-02 document and the Carsten's mail about addressing map for 16-bit addresses. I think it is a good solution for the address confusion problem. However, looks like there needs other precondition to make Multicast work properly and effectively in 6LowPAN. First condition is the MAC filter, as I mentioned in last mail, IEEE 802.15.4 MAC can't fliter Multicast frame, the reception and rejection algorithm are descripted as bellow in specification: - If a destination PAN identifier is included in the frame, it shall match macPANId or shall be the broadcast PAN identifier (0 x ffff). - If a short destination address is included in the frame, it shall match either macShortAddress or the broadcast address (0 x ffff). Otherwise, if an extended destination address is included in the frame, it shall match aExtendedAddress. According to this algorithm, when the MAC layer of some 802.15.4 node receive a frame with Multicast destination address, how will it judge the frame should be handled but not be discarded? For 802.15.4 MAC PIB could just hold one 64-bits EUI-64 address and one 16-bits short address(for node's unicast address), may be the only way to get Multicast frame is to set the MAC sublayer to promiscuous mode. By doing this job, Adaptation Layer could get all of frame arrived in MAC sublayer and filter what it want by itself, including Multicast frame. Unfortunately, the solution for the previous problem also cause another problem. That is how to foward the Multicast frame to right destinations(group members). The document "6LoWPAN Meeting 65 IETF Dallas Format Document changes" mentioned following possible method: dumb flooding, controlled flooding and unicasting to the PAN COORDINATOR. As my understanding, all three above still need 802.15.4 MAC broadcast and Adapatation Layer broadcast flooding relay to make all possible receiver get Multicast frame. The requirement of Adapatation Layer broadcast flooding relay is because not all of 802.15.4 node will be in the broadcast range of the sender in Mesh Topology, unlike in Ethernet. So, maybe we should need an Adaptation Multicast Route Potocol(like PIM-SM in Internet) to build a Multicast Tree when some node join some Multicast group. After the Multicast tree has been built, node in the tree will know where are the group members in and how to forward Multicast frame to them. In the matter of fact, we could also use the special Multicast address in a much simple way, that is just make Adaptation Layer be a Multicast frame filter. In this way, IPv6 Layer will tell Adaptation Layer which Multicast group it has joined, and Adaptation Layer will discard the frame not belong to these groups before handing it to IP Layer. However, if we want the sepcial Multicast address really do some work, controlled forwarding in Multicast Tree may be necessary. Otherwise, node will fill Multicast MAC address in Adaptation or MAC header but could only broadcast Multicast frame to all the node in the PAN. Actually, I think 6LowPANers will find a good way to solve the multicast problem eventually. But what I want to say is does it worth? For 802.15.4 MAC don't support multicast, we have to do all the work in Adaptation Layer. In LowPAN node, resource is limited(except energy, memory for code is tight either). If we make the protocol more complex, more code space will be needed. Take the platform we are using as an example, the Freescale MC9S08GB60 MCU has 60K Flash for code, hardware driver and 802.15.4 MAC library(supplied by Freescale) will take at least 33K, current Adaptation Layer will take about 12K(including Route and Topology Maintenance), this means only 15K is left for IPv6, NDP and up-layer. For our lab has implemented an IPv6/IPv4 dual protocol stack in ARM platform before, we consider 15K code space is very tight for a reduced IPv6 stack. The point is, if we could just use MAC broadcast to let IP Multicast work well, why not just do it? If we add more and more function to Adaptation Layer, I really worry about a low power and low cost device having the ability to run it. Thanks. Regards, Mario Mao _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-1825192179-1151169604=:65772 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I also have strong misgivings about adding more func= tionality like this and look to folks
implementing this (like yourselves= ) to provide feedback on how practical this all is. At any rate, the
cur= rent spec is clear that the multicast support is optional (it is, after all= , an optimization).

-gabriel

----- Original Message -= ---
From: Mario Mao <mariomao@gmail.com>
To: 6lowpan@ietf.orgSent: Saturday, May 20, 2006 4:40:16 AM
Subject: [6lowpan] Comments ab= out the use of Multicast Ability

=0A=0A=0A=0A =0A=0A =0A=0A
As far as I know, nobody's approached 802.15.4 about this. I have worded it
as additional constraints beyond 802.15.4 for 6lowpan operation.

-gabriel

----- Original Message ----
From: Samita Chakrabarti <samitac2@gmail.com>
To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Cc: Carsten Bormann <cabo@tzi.org>; 6lowpan@ietf.org
Sent: Saturday, June 24, 2006 4:15:40 PM
Subject: Re: [6lowpan] 6lowpan 16-bit address space map

Gabriel/Carsten:

Are the suggested 16bit MAC addresses only meant for 6lowpan usage?
Or they would be blessed by IEEE standards for 802.15.4 devices?

Thanks,
-Samita

On 6/24/06, gabriel montenegro <gabriel_montenegro_2000@yahoo.com> wrote:
>
>
> I've added a much simpler version, only mentioning those fields we are
> specifying in the document.
> Anything not currently specified can be defined later, right now the
> important thing is to reserve the
> relevant space.
>
> I include below the IANA section on 16-bit address format, as it currently
> looks.
>
> -gabriel
> ps - currently on vacation and with spotty email connectivity, but I'll be
> submitting this before the deadline.
>  This document creates a new IANA registry for the 16-bit short
>  address fields used in 6LoWPAN packets.
>
>  0 1
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
| 16-bit short Address |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>  Figure 11
>
>  These address fields MUST follow this format (referring to bit fields
>  in the order from 0 to 7):
>
>  O: The first bit SHALL be zero if the 16-bit address is a non-
>  multicast (e.g., unicast) address. This leaves 15 bits for the
>  actual address.
>
>  100: Bits 0,1 and 2 SHALL follow this pattern if the 16-bit address
>  is a multicast address. This leaves 13 bits for the actual
>  multicast address.
>
>  101, 110 or 111: These patterns for bits 0,1 and 2 are reserved. for
>  future assignment as per the policy mentioned above.
>
>
> ----- Original Message ----
> From: Carsten Bormann <cabo@tzi.org>
> To: 6lowpan@ietf.org
> Cc: Carsten Bormann <cabo@tzi.org>
> Sent: Friday, April 21, 2006 11:40:52 AM
> Subject: [6lowpan] 6lowpan 16-bit address space map
>
> Lowpanners,
>
> here is a more detailed idea of how the addressing map for 16-bit
> addresses could look like.  Comments welcome.
>
> 0xxxxxxxxxxxxxxx unicast addresses allocated by the PAN coordinator
> 100xxxxxxxxxxxxx special unicast addresses, e.g.
>       1000000000000000 PAN coordinator
>       1000000000000001 backup PAN coordinator (just making this up now)
>       allocation requires standards action
> 101xxxxxxxxxxxxx reserved (allocation requires standards action)
> 110xxxxxxxxxxxxx multicast addresses (mapping per format document)
> 111xxxxxxxxxxxxx special addresses, often multicast, e.g.
>       1111111111111110 (the 0xfffe thing from 802.15.4)
>       1111111111111111 radio-range-limited localcast to non-sleepers
>       allocation requires standards action
>
> I'm not so sure about using 100xxxxxxxxxxxxx for the PAN coordinator
> things etc; maybe we should use 111xxxxxxxxxxxxx for all "special"
> addresses to have more contiguous space reserved for future use.
>
> Gruesse, Carsten
>
>
> _______________________________________________
> 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
>
>
>

--0-629842257-1151300857=:60806-- --===============0691350641== 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 --===============0691350641==-- From 6lowpan-bounces@ietf.org Mon Jun 26 03:40:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuliF-0000fL-RF; Mon, 26 Jun 2006 03:40:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuliE-0000fD-Ph for 6lowpan@ietf.org; Mon, 26 Jun 2006 03:40:50 -0400 Received: from web81914.mail.mud.yahoo.com ([68.142.207.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FuliD-0005L5-DK for 6lowpan@ietf.org; Mon, 26 Jun 2006 03:40:50 -0400 Received: (qmail 30786 invoked by uid 60001); 26 Jun 2006 07:40:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=gyPUo7cRZ/gmeHJ+Bq9cGEF47CcTBuLrzCin6IoNxE2a86HzF5TDZE3RruXS/zTB5fatBKvJg4wTUX6FYjo2lKyBOcH3AwXlcpcbaK/9VSDT9WgkF94qzqF22fxCnPqYUp5HeTcUYUIvLR5KqSQ3PAsC6mNzGgIbaPgFFrDLNWs= ; Message-ID: <20060626074048.30784.qmail@web81914.mail.mud.yahoo.com> Received: from [200.21.187.148] by web81914.mail.mud.yahoo.com via HTTP; Mon, 26 Jun 2006 00:40:48 PDT Date: Mon, 26 Jun 2006 00:40:48 -0700 (PDT) From: gabriel montenegro To: 6lowpan@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [6lowpan] submitted draft-ietf-6lowpan-format-03.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============0777260446==" Errors-To: 6lowpan-bounces@ietf.org --===============0777260446== Content-Type: multipart/alternative; boundary="0-514685116-1151307648=:28619" --0-514685116-1151307648=:28619 Content-Type: text/plain; charset=us-ascii In the meantime, it's available at: http://www.geocities.com/gabriel_montenegro_2000/ Here's a list of changes: Changes from version draft-ietf-6lowpan-format-02.txt to version draft-ietf-6lowpan-format-03.txt are as follows: Interface Identifier derivation using 16-bit short addresses now using the PAN ID as well. Word of caution on the transient nature of 16 bit short addresses. Reassembly now also keying on destination and datagram_size. Mesh delivery header now allowing mix of 16/64 bit addresses. This leaves 6 bits for hops_left (64 hops is plenty). Added optional Multicast Address mapping patterned after that of ethernet. Clarified that all zero addresses must not be used (for either 16 or 64 bit formats). Added address format section to IANA considerations to define unicast, multicast and reserved address formats. Added Mesh Broadcast or Multicast Delivery Field. Created a new section on Addressing Modes. Sundry editorial changes. -gabriel --0-514685116-1151307648=:28619 Content-Type: text/html; charset=us-ascii
In the meantime, it's available at:

    http://www.geocities.com/gabriel_montenegro_2000/

Here's a list of changes:

   Changes from version draft-ietf-6lowpan-format-02.txt to version
   draft-ietf-6lowpan-format-03.txt are as follows:

      Interface Identifier derivation using 16-bit short addresses now
      using the PAN ID as well.

      Word of caution on the transient nature of 16 bit short addresses.

      Reassembly now also keying on destination and datagram_size.

      Mesh delivery header now allowing mix of 16/64 bit addresses.
      This leaves 6 bits for hops_left (64 hops is plenty).

      Added optional Multicast
 Address mapping patterned after that of
      ethernet.

      Clarified that all zero addresses must not be used (for either 16
      or 64 bit formats).

      Added address format section to IANA considerations to define
      unicast, multicast and reserved address formats.

      Added Mesh Broadcast or Multicast Delivery Field.

      Created a new section on Addressing Modes.


      Sundry editorial changes.

-gabriel
--0-514685116-1151307648=:28619-- --===============0777260446== 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 --===============0777260446==-- From 6lowpan-bounces@ietf.org Mon Jun 26 03:42:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuljw-0003DV-N8; Mon, 26 Jun 2006 03:42:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuljv-0003DP-UT for 6lowpan@ietf.org; Mon, 26 Jun 2006 03:42:35 -0400 Received: from web81913.mail.mud.yahoo.com ([68.142.207.50]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fuljv-0005Q3-Do for 6lowpan@ietf.org; Mon, 26 Jun 2006 03:42:35 -0400 Received: (qmail 94545 invoked by uid 60001); 26 Jun 2006 07:35:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=eKMYtS1C/etwNuFEGdx4HCij0MFDtFXPxP0DGCANsHO3dPXUFcDUkvdaVQG7HI5kMCb7uSmX8gx9RPEq7gPWfB0UD/w25JcZ+R5jEsJA/wwE1ZnhTwvWKws4UeRLFw1SPc0E8SCSB/+sU4NP6vfK1J19SHx4/ZvoOnX6on/8pLs= ; Message-ID: <20060626073554.94543.qmail@web81913.mail.mud.yahoo.com> Received: from [200.21.187.148] by web81913.mail.mud.yahoo.com via HTTP; Mon, 26 Jun 2006 00:35:54 PDT Date: Mon, 26 Jun 2006 00:35:54 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Comments about the use of Multicast Ability To: Samita Chakrabarti , Mario Mao In-Reply-To: <43b91d370606241724v3c0cb9f6u598533df2e8f2d3a@mail.gmail.com> MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabriel montenegro 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="===============1315733046==" Errors-To: 6lowpan-bounces@ietf.org --===============1315733046== Content-Type: multipart/alternative; boundary="0-956170842-1151307354=:88277" --0-956170842-1151307354=:88277 Content-Type: text/plain; charset=us-ascii Does your draft show that one does not need multicast to work for IPv6? Or does it show that one does not need multicast for ND? Admittedly, perhaps the main motivation to run multicast is ND, but there may be other reasons to run it as well as broadcast. I think what Mario et al have been experimenting with is a more general multicast/broadcast facility. Ian also mentioned this, though he suggested a mechanism (adaptation of MANETs SMF) different from what Mario suggested. Ian had suggested a sequence number of 16 bits, whereas Mario's experimenting with 8. Given that we now have address ranges, we can have different mesh delivery formats apply to different address ranges. I added some text to limit the applicability of the current mesh delivery format to cases when the destination address is a unicast address. I don't think we are ready to fully specify how a broadcast or multicast delivery mechanism should work. This is probably best done in a separate document. At any rate, I added a format for mesh delivery of broadcast/multicast packets which just adds a sequence number field, but left the full spec as out of scope. -gabriel ----- Original Message ---- From: Samita Chakrabarti To: Mario Mao Cc: 6lowpan@ietf.org Sent: Saturday, June 24, 2006 5:24:38 PM Subject: Re: [6lowpan] Comments about the use of Multicast Ability Hello Mario: > In practice, with the relatively simple way, the controlled flooding could just > solve the problem of how to multicasting. We find it still a high-costing method > to broadcast periodic Multicast IP packet(like Router Advertisement, > RFC2461). So, more details about the up-layer protocol(especially about > NDP) need be considered. For example, using an dynamic advertising > algorithm to reduce the broadcast times. > Please refer to http://www.ietf.org/internet-drafts/draft-chakrabarti-6lowpan-ipv6-nd-01.txt For the IPv6 neighbor discovery multicast and signaling optimization in 802.15.4 networks. Thus we don't need multicast to work to run IPv6 on 802.15.4. This is simple to implement and does not require much additional code. This fits well with 802.15.4 network topologies. We have several presentations of this draft in last IETFs; the wg thinks this work is important enough to move forward. Please provide your comments. Will be also interested to find out if anyone is willing to implement this draft? Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-956170842-1151307354=:88277 Content-Type: text/html; charset=us-ascii
Does your draft show that one does not need multicast to work for IPv6? Or does it show that
one does not need multicast for ND? Admittedly, perhaps the main motivation to run multicast
is ND, but there may be other reasons to run it as well as broadcast. I think what Mario et al
have been experimenting with is a more general multicast/broadcast facility. Ian also mentioned
this, though he suggested a mechanism (adaptation of MANETs SMF) different from what Mario suggested.
Ian had suggested a sequence number of 16 bits, whereas Mario's experimenting with 8.

Given that we now have address ranges, we can have different mesh delivery formats apply to
different address ranges. I added some text to limit the applicability of the current mesh delivery
format to cases when the destination address is a unicast address. I don't think we are ready to
fully specify how a broadcast or multicast delivery mechanism should work. This is probably best
done in a separate document. At any rate, I added a format for mesh delivery of broadcast/multicast
packets which just adds a sequence number field, but left the full spec as out of scope.

-gabriel

----- Original Message ----
From: Samita Chakrabarti <samitac2@gmail.com>
To: Mario Mao <mariomao@gmail.com>
Cc: 6lowpan@ietf.org
Sent: Saturday, June 24, 2006 5:24:38 PM
Subject: Re: [6lowpan] Comments about the use of Multicast Ability

Hello Mario:

> In practice, with the relatively simple way, the controlled flooding could just
> solve the problem of how to multicasting. We find it still a high-costing method
>  to broadcast periodic Multicast IP packet(like Router Advertisement,
> RFC2461). So, more details about the up-layer protocol(especially about
> NDP) need be considered. For example, using an dynamic advertising
> algorithm to reduce the broadcast times.
>

Please refer to
http://www.ietf.org/internet-drafts/draft-chakrabarti-6lowpan-ipv6-nd-01.txt

For the IPv6 neighbor discovery multicast and signaling optimization
in 802.15.4 networks. Thus we don't need multicast to work to run IPv6
on 802.15.4.
This is simple to implement and does not require much additional code.
This fits well with 802.15.4 network topologies.
We have several presentations of this draft in last IETFs; the wg thinks this
work is important enough to move forward. Please provide your comments.
Will be also interested to find out if anyone is willing to implement
this draft?

Thanks,
-Samita

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--0-956170842-1151307354=:88277-- --===============1315733046== 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 --===============1315733046==-- From 6lowpan-bounces@ietf.org Mon Jun 26 07:12:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fup0Z-0004Eu-EI; Mon, 26 Jun 2006 07:11:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fup0Y-0004BG-Nk for 6lowpan@ietf.org; Mon, 26 Jun 2006 07:11:58 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fup0X-00067x-3C for 6lowpan@ietf.org; Mon, 26 Jun 2006 07:11:58 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J1G00J4KSEI6R@mailout1.samsung.com> for 6lowpan@ietf.org; Mon, 26 Jun 2006 20:11:06 +0900 (KST) Received: from daniellaptop ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0J1G007PFSEIDZ@mmp2.samsung.com> for 6lowpan@ietf.org; Mon, 26 Jun 2006 20:11:06 +0900 (KST) Date: Mon, 26 Jun 2006 20:11:15 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] Fw: I-DACTION:draft-daniel-6lowpan-security-analysis-01.txt To: "Wassim Haddad (KI/EAB)" Message-id: <04c801c69911$3ddc4f60$6dc6dba8@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 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: <95D8C1105D54EB41864F8831E6C4EB7513FD72@ecamlmw720.eamcs.ericsson.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 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 Hi Wassim, Thanks your point. In principle, I doubt that SeND (and even OptiSeND) can be applied for 6lowpan environment, we need further study in the next version though. 6lowpan node is more power/resourse sensitive than you are referring to OptiSeND nodes in your proposal. I don't have a clear answer on that at this stage, so we am focusing on *analysis* first, not *solution*. Anyway, I will refer to your effort, and appreciate if you have more comments on NDP security analysis in conjunction with 6lowpan. Regards. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: "Wassim Haddad (KI/EAB)" To: Cc: <6lowpan@ietf.org>; "Wassim Haddad (KI/EAB)" Sent: Sunday, June 25, 2006 1:25 AM Subject: [6lowpan] Fw: I-DACTION:draft-daniel-6lowpan-security-analysis-01.txt Hi Daniel, You may be interested in taking a look to the ongoing work on Optimizing the SEND protocol: draft-haddad-mipshop-optisend-01 Regards, Wassim H. >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : IPv6 over Low Power WPAN Security Analysis > Author(s) : S. Park, et al. > >Daniel (Soohong Daniel Park) >Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 26 07:28:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FupGt-0001Hy-DS; Mon, 26 Jun 2006 07:28:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FupGr-0001Hi-RA for 6lowpan@ietf.org; Mon, 26 Jun 2006 07:28:49 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FupGp-0006Wv-D8 for 6lowpan@ietf.org; Mon, 26 Jun 2006 07:28:49 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J1G00JO0T676R@mailout1.samsung.com> for 6lowpan@ietf.org; Mon, 26 Jun 2006 20:27:43 +0900 (KST) Received: from daniellaptop ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0J1G003H4T674C@mmp2.samsung.com> for 6lowpan@ietf.org; Mon, 26 Jun 2006 20:27:43 +0900 (KST) Date: Mon, 26 Jun 2006 20:27:52 +0900 From: Soohong Daniel Park Subject: Re: [6lowpan] 6lowpan-nd version 2 To: Samita Chakrabarti , 6lowpan@ietf.org Message-id: <04fb01c69913$90578140$6dc6dba8@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 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: <43b91d370606241630n52d25c58jb3fb784e364a416e@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 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 Hi Samita, Please see my comments inline. > Erik and I have updated draft-chakrabarti-6lowpan-ipv6-nd-02.txt and > submitted for publication. The new update includes a section on generic > application of this draft for non-multicast, non-broadcast network. > At the last wg meeting, the request was made for such an update for > the Wimax effort on IPv6. Let me clarify one point, I remember the relevent discussion in Dallas. Yes, we definitely need this aspect, however 16ng WG (IP over IEEE 802.16) has been newly created in INT area and they will take care of this issue as one of WG deliverable. So, please toss it to that. Here is a 16ng WG approval; http://eeca16.sogang.ac.kr/pipermail/16ng/Week-of-Mon-20060619/000154.html > Two questions to the working group and the chairs: > > 1) Should this draft( 6lowpan-ipv6-nd) be published as a WG document ? I don't have a strong objection and the current document really looks good. However before that, we should trigger 6lowpan WG rechartering taking into account this issue and others concerned. In my memory, there are five items. - 6lowpan bootstrapping and IPv6 ND optimization - Stateful header compression problem statements - Recommendations for 6lowpan applications - 6lowpan mesh routing - 6lowpan security analysis Geoff and Carsten, what is going on in rechartering ? > 2) Are we OK with publishing the draft as "IPv6 Neighbor Discovery > Optimization > for IEEE 802.15.4 and other non-multicast networks" so that it contains > specifics on 6lowpan and a generic guideline for other relevant networks? Above. Regards. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 26 08:01:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fupmn-0001NR-OT; Mon, 26 Jun 2006 08:01:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fupmm-0001N6-8M for 6lowpan@ietf.org; Mon, 26 Jun 2006 08:01:48 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fupmk-00024X-V3 for 6lowpan@ietf.org; Mon, 26 Jun 2006 08:01:48 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 8A709800A5D; Mon, 26 Jun 2006 15:01:45 +0300 (EEST) Date: Mon, 26 Jun 2006 15:01:45 +0300 (EEST) From: Wassim Haddad To: Soohong Daniel Park Subject: Re: [6lowpan] Fw: I-DACTION:draft-daniel-6lowpan-security-analysis-01.txt In-Reply-To: <04c801c69911$3ddc4f60$6dc6dba8@daniellaptop> Message-ID: References: <95D8C1105D54EB41864F8831E6C4EB7513FD72@ecamlmw720.eamcs.ericsson.se> <04c801c69911$3ddc4f60$6dc6dba8@daniellaptop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 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 Hi Daniel, On Mon, 26 Jun 2006, Soohong Daniel Park wrote: > Thanks your point. > > In principle, I doubt that SeND (and even OptiSeND) > can be applied for 6lowpan environment, we need > further study in the next version though. => I agree with you that SEND is unusable (too heavy for even "normal" small mobile devices) but am not sure about your comment on OptiSEND. In fact, the One-way hash chains and symmetric keys (which are the main features in OptiSEND) are considered cheap enough to be used to authenticate messages in these environments. > 6lowpan node is more power/resourse sensitive than you are > referring to OptiSeND nodes in your proposal. => Can you please elaborate more on what you mean by "more"? > Anyway, I will refer to your effort, and appreciate > if you have more comments on NDP security analysis > in conjunction with 6lowpan. => OK thanks. Regards, Wassim H. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 26 22:05:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2x1-0001eM-J5; Mon, 26 Jun 2006 22:05:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2x0-0001du-1V for 6lowpan@ietf.org; Mon, 26 Jun 2006 22:05:14 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv2wx-0003Uv-Mc for 6lowpan@ietf.org; Mon, 26 Jun 2006 22:05:14 -0400 Received: by nf-out-0910.google.com with SMTP id d4so943540nfe for <6lowpan@ietf.org>; Mon, 26 Jun 2006 19:05:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DkiUkhbE2uCxUAJ8CnKmn1GnBR+fwS/OgDUySH3LtwGeM8EECDsK+CMPOejcWCowJsalQ8RI2ibhYK58EndEYtrXoACXwEtfmN+15k4YNyoRWKpst8sYpi0r03Qxhc5oQn81CSHaPEIDmhN4en8GCpYK+lFgQcgA64q4mKeKwnY= Received: by 10.49.91.12 with SMTP id t12mr5208062nfl; Mon, 26 Jun 2006 19:05:10 -0700 (PDT) Received: by 10.48.203.3 with HTTP; Mon, 26 Jun 2006 19:05:10 -0700 (PDT) Message-ID: <43b91d370606261905k4409d643u27fdc0fc5a4d0d39@mail.gmail.com> Date: Mon, 26 Jun 2006 19:05:10 -0700 From: "Samita Chakrabarti" To: "Soohong Daniel Park" Subject: Re: [6lowpan] 6lowpan-nd version 2 In-Reply-To: <04fb01c69913$90578140$6dc6dba8@daniellaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370606241630n52d25c58jb3fb784e364a416e@mail.gmail.com> <04fb01c69913$90578140$6dc6dba8@daniellaptop> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: 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 Hi Daniel, Please see my comments in-line. > > Erik and I have updated draft-chakrabarti-6lowpan-ipv6-nd-02.txt and > > submitted for publication. The new update includes a section on generic > > application of this draft for non-multicast, non-broadcast network. > > At the last wg meeting, the request was made for such an update for > > the Wimax effort on IPv6. > > Let me clarify one point, > > I remember the relevent discussion in Dallas. Yes, we definitely > need this aspect, however 16ng WG (IP over IEEE 802.16) > has been newly created in INT area and they will take care of > this issue as one of WG deliverable. So, please toss it to that. There is no conflict with 16ng ND with this work. As Erik and Basavaraj mentioned before that we need to make sure that 6lowpan-ND and 16ng ND modifications do not provide different solutions for the same problem. Because the solution presented in 6lowpan-ND document can be generally applicable to any other non-multicast/broadcast energy-efficient network (16ng is one of the immediate applications), the 'general applicability' of this draft may be useful for other type of power efficient networks as well. Thus the idea is that 16ng-ND draft can update its text based on the information in the general applicability section of the 6lowpan-ND draft. > Here is a 16ng WG approval; > http://eeca16.sogang.ac.kr/pipermail/16ng/Week-of-Mon-20060619/000154.html > > > Two questions to the working group and the chairs: > > > > 1) Should this draft( 6lowpan-ipv6-nd) be published as a WG document ? > > I don't have a strong objection and the current document really looks good. > However before that, we should trigger 6lowpan WG rechartering taking > into account this issue and others concerned. We have had extensive discussion on the usefulness of 6lowpan-ND work at the January Interim meeting. My understanding from that meeting is that IPv6 ND optimization is a no-brainer item in the new charter. So, I agree that it'll be good to see the 6lowpan charter updated. Thanks, -Samita > > In my memory, there are five items. > > - 6lowpan bootstrapping and IPv6 ND optimization > - Stateful header compression problem statements > - Recommendations for 6lowpan applications > - 6lowpan mesh routing > - 6lowpan security analysis > > Geoff and Carsten, what is going on in rechartering ? > > > 2) Are we OK with publishing the draft as "IPv6 Neighbor Discovery > > Optimization > > for IEEE 802.15.4 and other non-multicast networks" so that it contains > > specifics on 6lowpan and a generic guideline for other relevant networks? > > Above. > > > Regards. > > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 26 22:27:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv3Iq-00024h-10; Mon, 26 Jun 2006 22:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv3Io-00024c-6g for 6lowpan@ietf.org; Mon, 26 Jun 2006 22:27:46 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv3Im-0004aP-R4 for 6lowpan@ietf.org; Mon, 26 Jun 2006 22:27:46 -0400 Received: by nf-out-0910.google.com with SMTP id d4so945187nfe for <6lowpan@ietf.org>; Mon, 26 Jun 2006 19:27:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=s9sc5BztNx4mE4SDyi8FMIpPZQdqSA3nJUmUyTHDKH63Wqy6VLuH5b8BfsoI0wXycmrfjFIePbFPfajj2MOI0YtU8gOiQ80XIAsB2rX3XlA+rpLTDx6lCT6r9jIvk92TuoevfTCjKdcK4blw0DJUsrOmlc3wsG50LaRfmmN5tL8= Received: by 10.49.91.12 with SMTP id t12mr5217292nfl; Mon, 26 Jun 2006 19:27:44 -0700 (PDT) Received: by 10.48.203.3 with HTTP; Mon, 26 Jun 2006 19:27:44 -0700 (PDT) Message-ID: <43b91d370606261927i1b2fb20w88837c3646cad293@mail.gmail.com> Date: Mon, 26 Jun 2006 19:27:44 -0700 From: "Samita Chakrabarti" To: "gabriel montenegro" Subject: Re: [6lowpan] Comments about the use of Multicast Ability In-Reply-To: <20060626073554.94543.qmail@web81913.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370606241724v3c0cb9f6u598533df2e8f2d3a@mail.gmail.com> <20060626073554.94543.qmail@web81913.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Mario Mao , 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 On 6/26/06, gabriel montenegro wrote: > > > Does your draft show that one does not need multicast to work for IPv6? Or > does it show that > one does not need multicast for ND? Admittedly, perhaps the main motivation > to run multicast Yes. The latter. 6lowpan-ND draft shows that IPv6 ND can be run in a non-multicast or non-broadcast network. I did not mean to say that multicast is not needed at all for 6lowpan network. In IPv6, AFAIK, multicast is mostly needed for ND purpose including the RA/RS. However, there are other protocols on IPv6 that require multicast capability. So, I think researching into multicast capability for 6lowpan is a good idea. However, the comment was specifically about ND and my mail was answering that section of the comment. 6lowpan-ND solution is an easy extension to IPv6 ND and available now. > is ND, but there may be other reasons to run it as well as broadcast. I > think what Mario et al > have been experimenting with is a more general multicast/broadcast facility. > Ian also mentioned > this, though he suggested a mechanism (adaptation of MANETs SMF) different > from what Mario suggested. > Ian had suggested a sequence number of 16 bits, whereas Mario's > experimenting with 8. > MANET SMF multicast is related to multicast routing. MANET is also introducing something called NHDP (Neighborhood Discovery Protocol) which helps a node to discover its neighborhood up to 2 hops away. So, these are different than link multicat capability that IPv6 ND requires for address assignment and router advertisement and so on. > Given that we now have address ranges, we can have different mesh delivery > formats apply to > different address ranges. I added some text to limit the applicability of > the current mesh delivery > format to cases when the destination address is a unicast address. I don't > think we are ready to > fully specify how a broadcast or multicast delivery mechanism should work. > This is probably best > done in a separate document. At any rate, I added a format for mesh delivery > of broadcast/multicast > packets which just adds a sequence number field, but left the full spec as > out of scope. > OK. Thanks, -Samita > > > ----- Original Message ---- > From: Samita Chakrabarti > To: Mario Mao > Cc: 6lowpan@ietf.org > Sent: Saturday, June 24, 2006 5:24:38 PM > Subject: Re: [6lowpan] Comments about the use of Multicast Ability > > > Hello Mario: > > > In practice, with the relatively simple way, the controlled flooding could > just > > solve the problem of how to multicasting. We find it still a high-costing > method > > to broadcast periodic Multicast IP packet(like Router Advertisement, > > RFC2461). So, more details about the up-layer protocol(especially about > > NDP) need be considered. For example, using an dynamic advertising > > algorithm to reduce the broadcast times. > > > > Please refer to > http://www.ietf.org/internet-drafts/draft-chakrabarti-6lowpan-ipv6-nd-01.txt > > For the IPv6 neighbor discovery multicast and signaling optimization > in 802.15.4 networks. Thus we don't need multicast to work to run IPv6 > on 802.15.4. > This is simple to implement and does not require much additional code. > This fits well with 802.15.4 network topologies. > We have several presentations of this draft in last IETFs; the wg thinks > this > work is important enough to move forward. Please provide your comments. > Will be also interested to find out if anyone is willing to implement > this draft? > > Thanks, > -Samita > > _______________________________________________ > 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 Jun 26 22:54:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv3iY-0003rc-Mk; Mon, 26 Jun 2006 22:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv3iX-0003rX-R1 for 6lowpan@ietf.org; Mon, 26 Jun 2006 22:54:22 -0400 Received: from web60317.mail.yahoo.com ([209.73.178.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fv3iW-0007Gf-DA for 6lowpan@ietf.org; Mon, 26 Jun 2006 22:54:21 -0400 Received: (qmail 49132 invoked by uid 60001); 27 Jun 2006 02:54:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZLQgayJt2HEbcRTz8/aHxdh5z0fN4e0FXwV6d9bmhorVchDNHW1qoh3c2LIPEmx3Vb09qhFmhAMvD8INF7t4xbR0GmAXQUiBdjhvGKQypqZqb3ALgV9ePbTd/bSNUaodlLXodg6VKdWt26gWUxlOpqm9gHO4G33BGv88lUZ9Xnk= ; Message-ID: <20060627025420.49130.qmail@web60317.mail.yahoo.com> Received: from [67.166.240.5] by web60317.mail.yahoo.com via HTTP; Mon, 26 Jun 2006 19:54:20 PDT Date: Mon, 26 Jun 2006 19:54:20 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [6lowpan] 6lowpan-nd version 2 To: Samita Chakrabarti In-Reply-To: <43b91d370606261905k4409d643u27fdc0fc5a4d0d39@mail.gmail.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya 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="===============0579615823==" Errors-To: 6lowpan-bounces@ietf.org --===============0579615823== Content-Type: multipart/alternative; boundary="0-1267211731-1151376860=:48537" --0-1267211731-1151376860=:48537 Content-Type: text/plain; charset=us-ascii Hi Samita, ----- Original Message ---- From: Samita Chakrabarti To: Soohong Daniel Park Cc: 6lowpan@ietf.org Sent: Monday, June 26, 2006 9:05:10 PM Subject: Re: [6lowpan] 6lowpan-nd version 2 Hi Daniel, Please see my comments in-line. > > Erik and I have updated draft-chakrabarti-6lowpan-ipv6-nd-02.txt and > > submitted for publication. The new update includes a section on generic > > application of this draft for non-multicast, non-broadcast network. > > At the last wg meeting, the request was made for such an update for > > the Wimax effort on IPv6. > > Let me clarify one point, > > I remember the relevent discussion in Dallas. Yes, we definitely > need this aspect, however 16ng WG (IP over IEEE 802.16) > has been newly created in INT area and they will take care of > this issue as one of WG deliverable. So, please toss it to that. There is no conflict with 16ng ND with this work. As Erik and Basavaraj mentioned before that we need to make sure that 6lowpan-ND and 16ng ND modifications do not provide different solutions for the same problem. Because the solution presented in 6lowpan-ND document can be generally applicable to any other non-multicast/broadcast energy-efficient network (16ng is one of the immediate applications), the 'general applicability' of this draft may be useful for other type of power efficient networks as well. Thus the idea is that 16ng-ND draft can update its text based on the information in the general applicability section of the 6lowpan-ND draft. ==>There is no 16ng-ND draft, there is presently a draft which in part has the relay DAD which seems to be adopted from your draft. ==>can you be more specific? ==>Thanks, ==>--behcet > Here is a 16ng WG approval; > http://eeca16.sogang.ac.kr/pipermail/16ng/Week-of-Mon-20060619/000154.html > > > Two questions to the working group and the chairs: > > > > 1) Should this draft( 6lowpan-ipv6-nd) be published as a WG document ? > > I don't have a strong objection and the current document really looks good. > However before that, we should trigger 6lowpan WG rechartering taking > into account this issue and others concerned. We have had extensive discussion on the usefulness of 6lowpan-ND work at the January Interim meeting. My understanding from that meeting is that IPv6 ND optimization is a no-brainer item in the new charter. So, I agree that it'll be good to see the 6lowpan charter updated. Thanks, -Samita > > In my memory, there are five items. > > - 6lowpan bootstrapping and IPv6 ND optimization > - Stateful header compression problem statements > - Recommendations for 6lowpan applications > - 6lowpan mesh routing > - 6lowpan security analysis > > Geoff and Carsten, what is going on in rechartering ? > > > 2) Are we OK with publishing the draft as "IPv6 Neighbor Discovery > > Optimization > > for IEEE 802.15.4 and other non-multicast networks" so that it contains > > specifics on 6lowpan and a generic guideline for other relevant networks? > > Above. > > > Regards. > > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-1267211731-1151376860=:48537 Content-Type: text/html; charset=us-ascii
Hi Samita,

----- Original Message ----
From: Samita Chakrabarti <samitac2@gmail.com>
To: Soohong Daniel Park <soohong.park@samsung.com>
Cc: 6lowpan@ietf.org
Sent: Monday, June 26, 2006 9:05:10 PM
Subject: Re: [6lowpan] 6lowpan-nd version 2

Hi Daniel,

Please see my comments in-line.

> > Erik and I have updated draft-chakrabarti-6lowpan-ipv6-nd-02.txt and
> > submitted for publication. The new update includes a section on generic
> > application of this draft for non-multicast, non-broadcast network.
> > At the last wg meeting, the request was made for such an update  for
> > the Wimax effort on IPv6.
>
> Let me clarify one point,
>
> I remember the relevent discussion in Dallas. Yes, we definitely
> need this aspect, however 16ng WG (IP over IEEE 802.16)
> has been newly created in INT area and they will take care of
> this issue as one of WG deliverable. So, please toss it to that.

There is no conflict with 16ng ND with this work. As Erik and
Basavaraj mentioned
before that we need to make sure that 6lowpan-ND and 16ng ND modifications
do not provide different  solutions for the same problem. Because the solution
presented in 6lowpan-ND document can be generally applicable to any other
non-multicast/broadcast  energy-efficient network (16ng is one of the immediate
applications), the  'general applicability' of this
draft may be useful for other type of power efficient networks as well.

Thus the idea is that 16ng-ND draft can update its text based on the information
in the general applicability section of the 6lowpan-ND draft.
==>There is no 16ng-ND draft, there is presently a draft which in part has the relay DAD which seems to be adopted from your draft.
==>can you be more specific?
==>Thanks,
==>--behcet

> Here is a 16ng WG approval;
> http://eeca16.sogang.ac.kr/pipermail/16ng/Week-of-Mon-20060619/000154.html
>
> > Two questions to the working group and the chairs:
> >
> >  1) Should this draft( 6lowpan-ipv6-nd) be published as a WG document ?
>
> I don't have a strong objection and the current document really looks good.
> However before that, we should trigger 6lowpan WG rechartering taking
> into account this issue and others concerned.

We have had extensive discussion on the usefulness of 6lowpan-ND
work at the January Interim meeting. My understanding from that meeting is
that IPv6 ND optimization is a no-brainer item in the new charter.

So, I agree that it'll be good to see the 6lowpan charter updated.

Thanks,
-Samita

>
> In my memory, there are five items.
>
> - 6lowpan bootstrapping and IPv6 ND optimization
> - Stateful header compression problem statements
> - Recommendations for 6lowpan applications
> - 6lowpan mesh routing
> - 6lowpan security analysis
>
> Geoff and Carsten, what is going on in rechartering ?
>
> >  2) Are we OK with publishing the draft as "IPv6 Neighbor Discovery
> > Optimization
> >      for IEEE 802.15.4 and other non-multicast networks" so that it contains
> >      specifics on 6lowpan and a generic guideline for other relevant networks?
>
> Above.
>
>
> Regards.
>
> Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, SAMSUNG Electronics.
>

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--0-1267211731-1151376860=:48537-- --===============0579615823== 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 --===============0579615823==-- From 6lowpan-bounces@ietf.org Tue Jun 27 02:15:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6rU-0002sw-Bc; Tue, 27 Jun 2006 02:15:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6rT-0002sh-LT for 6lowpan@ietf.org; Tue, 27 Jun 2006 02:15:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv6rT-0006rz-Jk for 6lowpan@ietf.org; Tue, 27 Jun 2006 02:15:47 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fv6nu-00078A-2a for 6lowpan@ietf.org; Tue, 27 Jun 2006 02:12:10 -0400 Received: by nf-out-0910.google.com with SMTP id o63so937764nfa for <6lowpan@ietf.org>; Mon, 26 Jun 2006 23:12:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KR34upUPr+4eevvWxNFFMslU2NomxaeECfMx5pkwl9bVM0deXnoUg07kt1NpaeAdUzojWDyAom2VMeLChLdOxdp0O9h3Ob9Gy/YQ7RcHT8MmFFOC9BRn13g0blu1p8N0SY/HCknjMC5aUrAuV6UJT4pPl8lIkbH6wVVPH/Hbh5Y= Received: by 10.49.42.5 with SMTP id u5mr5319494nfj; Mon, 26 Jun 2006 23:12:04 -0700 (PDT) Received: by 10.48.203.3 with HTTP; Mon, 26 Jun 2006 23:12:04 -0700 (PDT) Message-ID: <43b91d370606262312r56ed6044jf68a32f7870282ce@mail.gmail.com> Date: Mon, 26 Jun 2006 23:12:04 -0700 From: "Samita Chakrabarti" To: "Behcet Sarikaya" Subject: Re: [6lowpan] 6lowpan-nd version 2 In-Reply-To: <20060627025420.49130.qmail@web60317.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370606261905k4409d643u27fdc0fc5a4d0d39@mail.gmail.com> <20060627025420.49130.qmail@web60317.mail.yahoo.com> X-Spam-Score: -2.5 (--) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: 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 HI Behcet, On 6/26/06, Behcet Sarikaya wrote: > > > Hi Samita, > > > ----- Original Message ---- > From: Samita Chakrabarti > To: Soohong Daniel Park > Cc: 6lowpan@ietf.org > Sent: Monday, June 26, 2006 9:05:10 PM > Subject: Re: [6lowpan] 6lowpan-nd version 2 > > > Hi Daniel, > > Please see my comments in-line. > > > > Erik and I have updated > draft-chakrabarti-6lowpan-ipv6-nd-02.txt and > > > submitted for publication. The new update includes a section on generic > > > application of this draft for non-multicast, non-broadcast network. > > > At the last wg meeting, the request was made for such an update for > > > the Wimax effort on IPv6. > > > > Let me clarify one point, > > > > I remember the relevent discussion in Dallas. Yes, we definitely > > need this aspect, however 16ng WG (IP over IEEE 802.16) > > has been newly created in INT area and they will take care of > > this issue as one of WG deliverable. So, please toss it to that. > > There is no conflict with 16ng ND with this work. As Erik and > Basavaraj mentioned > before that we need to make sure that 6lowpan-ND and 16ng ND modifications > do not provide different solutions for the same problem. Because the > solution > presented in 6lowpan-ND document can be generally applicable to any other > non-multicast/broadcast energy-efficient network (16ng is > one of the immediate > applications), the 'general applicability' of this > draft may be useful for other type of power efficient networks as well. > > Thus the idea is that 16ng-ND draft can update its text based on the > information > in the general applicability section of the 6lowpan-ND draft. > ==>There is no 16ng-ND draft, there is presently a draft which in part has > the relay DAD which seems to be adopted from your draft. > ==>can you be more specific? Good point. There is no 16ng-ND draft. 16ng has a document, draft-madanapalli-ipv6-over-802.16-ipv6cs-00 which talks about IPv6 issues in 802.16 networks. 6lowpan-ND optimizations are applicable to those situations as well, in general, but they need to apply the ideas into their own network components, such as ASN-GW as opposed to 802.15.4 co-ordinators. Thus at Dallas meeting it was agreed that either we split the 6lowpan-ND for generic and 6lowpan-specific solutions or update the 6lowpan-ND draft with a separate section for generic behavior. IPv6-ND-over-Foo networks then can refer to this general section for applying into their own situations. Regards, -Samita > ==>Thanks, > ==>--behcet > > > > Here is a 16ng WG approval; > > > http://eeca16.sogang.ac.kr/pipermail/16ng/Week-of-Mon-20060619/000154.html > > > > > Two questions to the working group and the chairs: > > > > > > 1) Should this draft( 6lowpan-ipv6-nd) be published as a WG document ? > > > > I don't have a strong objection and the current document really looks > good. > > However before that, we should trigger 6lowpan WG rechartering taking > > into account this issue and others concerned. > > We have had extensive discussion on the usefulness of 6lowpan-ND > work at the January Interim meeting. My understanding from that meeting is > that IPv6 ND optimization is a no-brainer item in the new charter. > > So, I agree that it'll be good to see the 6lowpan charter updated. > > Thanks, > -Samita > > > > > In my memory, there are five items. > > > > - 6lowpan bootstrapping and IPv6 ND optimization > > - Stateful header compression problem statements > > - Recommendations for 6lowpan applications > > - 6lowpan mesh routing > > - 6lowpan security analysis > > > > Geoff and Carsten, what is going on in rechartering ? > > > > > 2) Are we OK with publishing the draft as "IPv6 Neighbor Discovery > > > Optimization > > > for IEEE 802.15.4 and other non-multicast networks" so that it > contains > > > specifics on 6lowpan and a generic guideline for other relevant > networks? > > > > Above. > > > > > > Regards. > > > > Daniel (Soohong Daniel Park) > > Mobile Convergence Laboratory, SAMSUNG Electronics. > > > > _______________________________________________ > 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 Tue Jun 27 10:40:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEjT-0006ol-6K; Tue, 27 Jun 2006 10:40:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEjS-0006jM-2a for 6lowpan@ietf.org; Tue, 27 Jun 2006 10:40:02 -0400 Received: from mh1.eu.ntt.net ([212.119.0.10]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FvEj1-0002MT-Rc for 6lowpan@ietf.org; Tue, 27 Jun 2006 10:39:37 -0400 Received: (qmail 3980 invoked by uid 2101); 27 Jun 2006 15:28:24 +0100 Received: from julien.IETF@laposte.net by mh1 by uid 0 with qmail-scanner-1.22st (clamdscan: 0.85.1. spamassassin: 3.0.4. perlscan: 1.22st. Clear:RC:1(212.119.9.178):. Processed in 0.500815 secs); 27 Jun 2006 14:28:24 -0000 Received: from unknown (HELO ?192.168.1.117?) (212.119.9.178) by mx1.eu.ntt.net with SMTP; 27 Jun 2006 15:28:23 +0100 From: Julien Laganier To: 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd version 2 User-Agent: KMail/1.8.2 References: <43b91d370606241630n52d25c58jb3fb784e364a416e@mail.gmail.com> <04fb01c69913$90578140$6dc6dba8@daniellaptop> <43b91d370606261905k4409d643u27fdc0fc5a4d0d39@mail.gmail.com> In-Reply-To: <43b91d370606261905k4409d643u27fdc0fc5a4d0d39@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Date: Tue, 27 Jun 2006 16:28:30 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200606271628.31520.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 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 Hi Samita and Daniel, On Tuesday 27 June 2006 04:05, Samita Chakrabarti wrote: > Hi Daniel, > > Please see my comments in-line. > > > > Erik and I have updated > > > draft-chakrabarti-6lowpan-ipv6-nd-02.txt and submitted for > > > publication. The new update includes a section on generic > > > application of this draft for non-multicast, non-broadcast > > > network. At the last wg meeting, the request was made for such > > > an update for the Wimax effort on IPv6. > > > > Let me clarify one point, > > > > I remember the relevent discussion in Dallas. Yes, we definitely > > need this aspect, however 16ng WG (IP over IEEE 802.16) > > has been newly created in INT area and they will take care of > > this issue as one of WG deliverable. So, please toss it to that. > > There is no conflict with 16ng ND with this work. As Erik and > Basavaraj mentioned > before that we need to make sure that 6lowpan-ND and 16ng ND > modifications do not provide different solutions for the same > problem. Because the solution presented in 6lowpan-ND document can > be generally applicable to any other non-multicast/broadcast > energy-efficient network (16ng is one of the immediate > applications), the 'general applicability' of this > draft may be useful for other type of power efficient networks as > well. > > Thus the idea is that 16ng-ND draft can update its text based on > the information in the general applicability section of the > 6lowpan-ND draft. Until today I was unaware of existence of Relay-DAD in 6lowpan and 16ng (silly me ;-) As I mentionned already on the 16ng mailing list today: In a draft I co-author (available there until it shows up in ID rep: ( Date: Tue, 27 Jun 2006 18:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: 6lowpan@lists.ietf.org Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-format-03.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, N. Kushalnagar Filename : draft-ietf-6lowpan-format-03.txt Pages : 29 Date : 2006-6-27 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-03.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-03.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-03.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-6-27150904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6lowpan-format-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6lowpan-format-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27150904.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--