From 6lowpan-bounces@ietf.org Fri Mar 02 02:34:33 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN2HU-0006j7-U4; Fri, 02 Mar 2007 02:34:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN2HS-0006ir-Bb for 6lowpan@lists.ietf.org; Fri, 02 Mar 2007 02:34:18 -0500 Received: from email2.etri.re.kr ([129.254.16.132] helo=email2.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN2HQ-0006TM-KA for 6lowpan@lists.ietf.org; Fri, 02 Mar 2007 02:34:18 -0500 Received: from etri964caf1384 ([129.254.112.135]) by email2.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 16:39:03 +0900 Message-ID: <00bf01c75c9d$2db0f0a0$8770fe81@etri964caf1384> From: "Dominik Kaspar" To: "Ian Chakeres" References: <00e001c75ada$4f4068a0$8770fe81@etri964caf1384> <374005f30702280900x745fa0c5w5e1c4d225184d075@mail.gmail.com> Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements Date: Fri, 2 Mar 2007 16:34:14 +0900 Organization: ETRI MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 02 Mar 2007 07:39:03.0178 (UTC) FILETIME=[D97C6EA0:01C75C9D] X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: 6lowpan@lists.ietf.org, manet@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 Ian, all, Ian, thanks a lot for your fast reply and detailed commenting on the "6LoWPAN Mesh Routing Requirements" draft [http://www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.txt]. I'm taking the right to post this answer to both the 6lowpan and MANET working groups, as MANET folks might be interested in this discussion as well. Ian, I find your inputs very reasonable, but they made me feel that the term "6lowpan" is not yet defined precisely enough to set up a strict set of 6lowpan routing requirements. For example, you give me the scenario of a 6lowpan network, in which all devices are powered and power usage is not important. But if I read the "6lowpan Problem Statement" [http://tools.ietf.org/wg/6lowpan/draft-ietf-6lowpan-problem], I'm not sure if such a set-up could still be called a 6lowpan, because that document explains that in a LoWPAN "typically, some or all devices are battery operated." This draft's intention is to provide the primary design goals of 6lowpan mesh routing and to stimulate responses for defining a set of requirements. The requirements I listed are still as vague as the term "6lowpan" itself, not at all proven and not fixed yet. I will keep all of your detailed comments on the requirements in mind for a next revision. Also, it has already been my intention to include a Section about what exactly the differences are between routing in a MANET and in a LoWPAN. Best regards, Dominik ----- Original Message ----- From: "Ian Chakeres" To: "Dominik Kaspar" Cc: <6lowpan@lists.ietf.org> Sent: Thursday, March 01, 2007 2:00 AM Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements > > Good to see some requirements for 6lowpan routing. > > Personally, I'd like to know what can't be done with MANET protocols > and why. Hopefully, a future version will include this information. If > you have any comments please send them to me or the MANET list. > > Ian > > I have some quick comments about the document. > > I don't think LQI by itself should be used. LQI must be matched with > other indicators to make good decisions. LQI can be bad for routing. > Similarly, shortest path can be bad. > > I think that operating with low routing state should be an > additionally goal. For example, if devices have only 32 forwarding > entries available. This fact could probably be captured in one of the > existing sections. > > Regarding the requirements section: > > I think that R2 is a bad requirement. I would instead say that routing > should be efficient. Efficiency can be defined in many ways. There > might be 6lowpan networks where all devices are power so power usage > is not important. Alternatively there might be nodes that choose not > to participate even though they have energy. I think that requiring > minimal energy routing is too harsh and unrealistic. > > R3. I would say that 6lowpan works below IP. Therefore, > interconnection is not seamless but below IP. Some device will need to > bridge (PAN coordinator or gateway) this gap. For example, RFD edge > devices will likely not include this capability. > > R4. I'm not sure that routing needs to be aware of sleeping nodes. We > could reverse the requirement and say that sleeping nodes must be > aware of routing. Or we could create a routing protocol that should > work independent of the sleep schedule. For example, flooding. > > R5. How do we measure simplicity and robustness? How much simplicity > and robustness are required by the various 6lowpan players? > > R6. How mobile? How dynamic? > > R7. Are you referring to IPv6 ND or routing (L2 in this case) > neighbor(hood) discovery? > > R9. What is the scalability requirement? How many nodes & at what density? > > R10. Is L2 (WEP like) security enough? > > Ian > > > On 2/27/07, Dominik Kaspar wrote: >> Hi all, >> >> A new Internet-Draft has just been submitted to emphasize the importance >> of >> mesh routing in LoWPANs. I believe that well thought-out mesh routing is >> a >> vital precondition for fully functional LoWPANs and should be discussed >> in >> more detail within the 6lowpan working group. >> >> Comments are welcomed for the Internet-Draft titled: >> "Design Goals and Requirements for 6LoWPAN Mesh Routing" >> >> Abstract: >> This document defines the problem statement, design goals, and >> requirements >> for mesh routing in low-power wireless personal area networks (LoWPANs). >> >> A URL for this Internet-Draft is: >> www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.txt >> >> Best regards, >> Dominik >> >> >> >> _______________________________________________ >> 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 Fri Mar 02 11:06:03 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNAGW-00060h-6Z; Fri, 02 Mar 2007 11:05:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNAGV-00060L-68 for 6lowpan@lists.ietf.org; Fri, 02 Mar 2007 11:05:51 -0500 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNAGS-0003AG-8o for 6lowpan@lists.ietf.org; Fri, 02 Mar 2007 11:05:51 -0500 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Sat, 3 Mar 2007 01:10:34 +0900 Priority: normal X-ReadCheckName: 6lowpan%40lists.ietf.org Thread-Topic: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements X-ReadCheckMessageID: <28bf09c7-e09b-41b2-abe8-8988ce7e9940@etri.re.kr> Thread-Index: Acdc5U7xiwfA/0stSceaCaIEMBlA6Q== From: =?ks_c_5601-1987?B?sei/67/u?= To: "Ian Chakeres" , "Dominik Kaspar" Bcc: Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements Date: Sat, 3 Mar 2007 01:10:34 +0900 Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCDC97y8tOvAzsXNs90gx6XB2A==?= =?ks_c_5601-1987?B?v6yxuMbALCC047Tn?= Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Content-class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 X-OriginalArrivalTime: 02 Mar 2007 16:10:34.0740 (UTC) FILETIME=[4F152340:01C75CE5] X-Spam-Score: 3.7 (+++) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ks_c_5601-1987?B?sei/67/u?= 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="===============1298037326==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1298037326== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----=_NextPart_000_BF6F_01C75D30.BEDB6090" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_BF6F_01C75D30.BEDB6090 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 ------=_NextPart_000_BF6F_01C75D30.BEDB6090 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy Ij4NCjxESVY+Jmd0OzxCUj4mZ3Q7SSBkb24ndCB0aGluayBMUUkgYnkgaXRzZWxmIHNob3VsZCBi ZSB1c2VkLiBMUUkgbXVzdCBiZSBtYXRjaGVkIHdpdGg8QlI+Jmd0O290aGVyIGluZGljYXRvcnMg dG8gbWFrZSBnb29kIGRlY2lzaW9ucy4gPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5J IGFncmVlLiBCdXQsIGluIG15IG9waW5pb24sIDxCUj5MUUkgaXMgbGlrZWx5IHRvIGJlIHRoZSBw cmltYXJ5IGtleS48QlI+VGhlIHJlYXNvbiBpcyBzYXZpbmcgVENPLjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+Jmd0O0xRSSBjYW4gYmUgYmFkIGZvciByb3V0aW5nLjxCUj4mZ3Q7U2lt aWxhcmx5LCBzaG9ydGVzdCBwYXRoIGNhbiBiZSBiYWQuPEJSPiZndDs8QlI+Jmd0O0kgdGhpbmsg dGhhdCBvcGVyYXRpbmcgd2l0aCBsb3cgcm91dGluZyBzdGF0ZSBzaG91bGQgYmUgYW48QlI+Jmd0 O2FkZGl0aW9uYWxseSBnb2FsLiBGb3IgZXhhbXBsZSwgaWYgZGV2aWNlcyBoYXZlIG9ubHkgMzIg Zm9yd2FyZGluZzxCUj4mZ3Q7ZW50cmllcyBhdmFpbGFibGUuIFRoaXMgZmFjdCBjb3VsZCBwcm9i YWJseSBiZSBjYXB0dXJlZCBpbiBvbmUgb2YgdGhlPEJSPiZndDtleGlzdGluZyBzZWN0aW9ucy48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkdvb2QgcG9pbnQuPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj5NeSBzYWxlcyBleHBlcmllbmNlIHRhdWdodCBtZSA8QlI+dGhhdCB3 ZSBoYWQgdG8gc3RydWdnbGUgdG8gc2F2ZSBhbnkgY29zdCBpc3N1ZXMuPEJSPlRoZW4gd2UgY291 bGQgYmUgd2lubmVyIGFuZCA8QlI+b3VyIHByb2R1Y3RzIG1hZGUgb3VyIGN1c3RvbWVycyBzYXZl IHRoZWlyIFRDTy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkEgaGFyc2ggc3lzdGVt IHNwZWNpZmljYXRpb24gaXMgYSBuYXR1cmFsIGNob2ljZSBhbmQ8QlI+dGhlIGxvdyByb3V0aW5n IHN0YXRlIG11c3QgYmUgYSBnb2FsIGFzIHdlbGwgYXMgYSByZXF1aXJlbWVudC48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZndDs8QlI+Jmd0O1JlZ2FyZGluZyB0aGUgcmVxdWlyZW1l bnRzIHNlY3Rpb246PEJSPiZndDs8QlI+Jmd0O0kgdGhpbmsgdGhhdCBSMiBpcyBhIGJhZCByZXF1 aXJlbWVudC4gSSB3b3VsZCBpbnN0ZWFkIHNheSB0aGF0IHJvdXRpbmc8QlI+Jmd0O3Nob3VsZCBi ZSBlZmZpY2llbnQuIEVmZmljaWVuY3kgY2FuIGJlIGRlZmluZWQgaW4gbWFueSB3YXlzLiBUaGVy ZTxCUj4mZ3Q7bWlnaHQgYmUgNmxvd3BhbiBuZXR3b3JrcyB3aGVyZSBhbGwgZGV2aWNlcyBhcmUg cG93ZXIgc28gcG93ZXIgdXNhZ2U8QlI+Jmd0O2lzIG5vdCBpbXBvcnRhbnQuIEFsdGVybmF0aXZl bHkgdGhlcmUgbWlnaHQgYmUgbm9kZXMgdGhhdCBjaG9vc2Ugbm90PEJSPiZndDt0byBwYXJ0aWNp cGF0ZSBldmVuIHRob3VnaCB0aGV5IGhhdmUgZW5lcmd5LiBJIHRoaW5rIHRoYXQgcmVxdWlyaW5n PEJSPiZndDttaW5pbWFsIGVuZXJneSByb3V0aW5nIGlzIHRvbyBoYXJzaCBhbmQgdW5yZWFsaXN0 aWMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JbiBteSBvcGluaW9uLCA8QlI+bW9z dCA2bG93cGFuIGRldmljZXMgYXJlIHBvd2VyZWQgYnkgYmF0dGVyeSBhbmQgPEJSPlRoZSBiYXR0 ZXJ5IHBvd2VyIG11c3QgYmUgdGhlIHdlYWtlc3QgcG9pbnQgaW4gYnVzaW5lc3MuPC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj5BcyB0aW1lIGdvZXMgYWZ0ZXIgd2lyZWxlc3MgZGV2aWNl cyBoYXZlIGJlZW4gaW5zdGFsbGVkLDxCUj5tYW5hZ2VtZW50IGNvc3QsIGZvciBleGFtcGxlcywg YmF0dGVyeSBjb3N0LCBsYWJvciBjb3N0IGZvciA8QlI+YmF0dGVyeSBjaGFuZ2UsIG1haW50ZW5h bmNlIGNvc3QsIHJlbW90ZSBtb25pdG9yaW5nIGFuZCBtYW5hZ2VtZW50PEJSPmNvc3QsIGV0Yy4g d2lsbCBvdmVyd2hlbG0gaW5zdGFsbGF0aW9uIGNvc3QuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj5NaW5pbWFsIGVuZXJneSB1c2FnZSBpcyB3b3J0aCBhZG9wdGluZyBmb3IgcmVxdWly ZW1lbnQgdG88QlI+c2F2ZSBiYXR0ZXJ5IGNvc3QgYW5kIHJlbGV2YW50IGxhYm9yIGNvc3QsIEkg dGhpbmsuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4iaGFyc2ggYW5kIHVucmVhbGlz dGljIiBpcyBhIGdvb2QgZXhwcmVzc2lvbiA8QlI+YnV0IHNvbHZpbmcgaXQgbXVzdCBiZSBhIHRl Y2huaWNhbCB0YXJnZXQuPC9ESVY+DQo8RElWPjxCUj4mZ3Q7UjQuIEknbSBub3Qgc3VyZSB0aGF0 IHJvdXRpbmcgbmVlZHMgdG8gYmUgYXdhcmUgb2Ygc2xlZXBpbmcgbm9kZXMuIFdlPEJSPiZndDtj b3VsZCByZXZlcnNlIHRoZSByZXF1aXJlbWVudCBhbmQgc2F5IHRoYXQgc2xlZXBpbmcgbm9kZXMg bXVzdCBiZTxCUj4mZ3Q7YXdhcmUgb2Ygcm91dGluZy4gT3Igd2UgY291bGQgY3JlYXRlIGEgcm91 dGluZyBwcm90b2NvbCB0aGF0IHNob3VsZDxCUj4mZ3Q7d29yayBpbmRlcGVuZGVudCBvZiB0aGUg c2xlZXAgc2NoZWR1bGUuIEZvciBleGFtcGxlLCBmbG9vZGluZy48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPkludGVyZXN0aW5nIHJldmVyc2lvbi48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPkZpcnN0IG9mIGFsbCwgdGhlIG1lYW5pbmcgb2YgInNsZWVwaW5nIiBuZWVkcyB0 byBiZSBjbGFycmlmaWVkLjxCUj5BcyBmYXIgYXMgSSBrbm93LCAic2xlZXBpbmciIGlzIG1haW5s eSBoaWJlcm5hdGlvbiBvZiA8QlI+UkYgdHJhbnNjZWl2ZXIuIDwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+SWYgcm91dGluZyBpcyBhd2FyZSBvZiBzbGVlcGluZyBub2Rlcywgcm91dGlu ZyBjYW4gY2hvb3NlPEJSPmFuIGFsdGVybmF0aXZlIHBhdGguIEJ1dCBpZiBzbGVlcGluZyBub2Rl cyBhcmUgYXdhcmUgb2Ygcm91dGluZyw8QlI+dGhleSBjYW5ub3QgdGFrZSBhY3Rpb25zIGZvciBy b3V0aW5nIGFjdGl2aXRpZXMuPC9ESVY+DQo8RElWPjxCUj5UaGF0J3MgbXkgdW5kZXJzdGFuZGlu Zy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZndDs8QlI+Jmd0O1I1LiBIb3cgZG8g d2UgbWVhc3VyZSBzaW1wbGljaXR5IGFuZCByb2J1c3RuZXNzPyBIb3cgbXVjaCBzaW1wbGljaXR5 PEJSPiZndDthbmQgcm9idXN0bmVzcyBhcmUgcmVxdWlyZWQgYnkgdGhlIHZhcmlvdXMgNmxvd3Bh biBwbGF5ZXJzPzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhlb3JldGljYWxseSBn b29kIHF1ZXN0aW9uLjwvRElWPg0KPERJVj48QlI+VGhlIGF1dGhvcnMgbmVlZCB0byB0aGluayBh Ym91dCBob3cgdG8gbWVhc3VyZSB0aGVtLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ QnkgdGhlIHdheSwganVzdCBteSBjdXJpb3NpdHkgPEJSPmJlY2F1c2UgSSdtIGEgbmV3YmllIGF0 IHJvdXRpbmcgcHJvdG9jb2xzLjxCUj5BcmUgdGhlcmUgYW55IG1ldHJpY3MgZm9yIG90aGVyIHJv dXRpbmcgcHJvdG9jb2xzIGluIHRlcm1zIG9mPEJSPnNpbXBsaWNpdHkgYW5kIHJvYnVzdG5lc3M/ IElmIHRoZXkgZG9uJ3QgdXNlIHRoZSB0ZXJtcywgPEJSPmhvdyBhYm91dCBlZmZpY2llbmN5IG9y IHNjYWxhYmlsaXR5PyA8QlI+QW5zd2VycyBjb3VsZCBiZSBnb29kIHJlZmVyZW5jZSB0byB0YWNr bGUgdGhlIHF1ZXN0aW9ucy4gPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7PEJS PiZndDtSNi4gSG93IG1vYmlsZT8gSG93IGR5bmFtaWM/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj5BcyBpbiB0aGUgY2FzZSBvZiBSNSw8QlI+dGhlIGF1dGhvcnMgbmVlZCB0byBjaGFu Z2UgdGhlIHdheSB0byBleHByZXNzIHRoZSByZXF1aXJlbWVudHMsPEJSPkkgdGhpbmsuPC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7PEJSPiZndDtSNy4gQXJlIHlvdSByZWZlcnJp bmcgdG8gSVB2NiBORCBvciByb3V0aW5nIChMMiBpbiB0aGlzIGNhc2UpPEJSPiZndDtuZWlnaGJv cihob29kKSBkaXNjb3Zlcnk/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5Ob3QgY29u Y2VybmluZyBhYm91dCB0aGUgUjcuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5BcyBh biBlbmQgdXNlciBvZiB3aXJlbGVzcyBzZW5zb3Igbm9kZXMgYW5kIG5ldHdvcmssPEJSPkkgaGF0 ZSB2NiBORCBhbmQgdjQgQVJQIGJlY2F1c2UgdGhleSBjb25zdW1lIG15IGJhdHRlcnkgYSBsb3Qu PC9ESVY+DQo8RElWPjxCUj5Gb3IgbXkgc2ltcGxlIHNlbnNvciBuZXR3b3JrLCA8QlI+Zml4ZWQg bWFudWFsIGNvbmZpZ3VyYXRpb24gaXMgZW5vdWdoLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+Jmd0O1IxMC4gSXMgTDIgKFdFUCBsaWtlKSBzZWN1cml0eSBlbm91Z2g/PC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj5JbiB0ZXJtcyBvZiBpbmZvcm1hdGlvbiBzZWN1cml0eSwg TDIgc2VjdXJpdHkgaXMgbm90IGVub3VnaCBidXQ8QlI+YSBtaW5pbWFsIHJlcXVpcmVtZW50IEkg dGhpbmsuIEwzIG9yIEw0IHNlY3VyaXR5IGlzIGEgdG91Z2g8QlI+cmVxdWlyZW1lbnQgZm9yIHRp bnkgZGV2aWNlcy4gPEJSPklmIGhpZ2hlciBsYXllciBzZWN1cml0eSBpcyByZXF1aXJlZCwgc3lz dGVtIHNwZWNpZmljYXRpb24gaGFzIHRvPEJSPmJlIHVwZ3JhZGVkLiBTbywgaW4gbXkgb3Bpbmlv biwgTDIgc2VjdXJpdHkgY291bGQgYmUgPEJSPmEgcmVhc29uYWJsZSBzb2x1dGlvbi48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxCUj5SZWdhcmRzLDxCUj5Ra2ltPC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48QlI+LS0tLS1PcmlnaW5hbC0tLS0tPEJSPjxCPkZyb206PC9C PiAiSWFuIENoYWtlcmVzIiAmbHQ7aWFuLmNoYWtlcmVzQGdtYWlsLmNvbSZndDs8QlI+PEI+RnJv bSBEYXRlOjwvQj4gMjAwNy0wMy0wMSC/wMD8IDI6MDA6MTE8QlI+PEI+VG86PC9CPiAiRG9taW5p ayBLYXNwYXIiICZsdDtkb21pbmlrQGV0cmkucmUua3ImZ3Q7PEJSPjxCPkNjOjwvQj4gIjZsb3dw YW5AbGlzdHMuaWV0Zi5vcmciICZsdDs2bG93cGFuQGxpc3RzLmlldGYub3JnJmd0OzxCUj48Qj5T dWJqZWN0OjwvQj4gUmU6IFs2bG93cGFuXSBGb3IgY29tbWVudHM6IDZMb1dQQU4gTWVzaCBSb3V0 aW5nIFJlcXVpcmVtZW50czxCUj48QlI+DQo8RElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9w bGFpbiBmb3JtYXQgLS0+PEJSPg0KPFA+PEZPTlQgc2l6ZT0yPkdvb2QgdG8gc2VlIHNvbWUgcmVx dWlyZW1lbnRzIGZvciA2bG93cGFuIHJvdXRpbmcuPEJSPjxCUj5QZXJzb25hbGx5LCBJJ2QgbGlr ZSB0byBrbm93IHdoYXQgY2FuJ3QgYmUgZG9uZSB3aXRoIE1BTkVUIHByb3RvY29sczxCUj5hbmQg d2h5LiBIb3BlZnVsbHksIGEgZnV0dXJlIHZlcnNpb24gd2lsbCBpbmNsdWRlIHRoaXMgaW5mb3Jt YXRpb24uIElmPEJSPnlvdSBoYXZlIGFueSBjb21tZW50cyBwbGVhc2Ugc2VuZCB0aGVtIHRvIG1l IG9yIHRoZSBNQU5FVCBsaXN0LjxCUj48QlI+SWFuPEJSPjxCUj5JIGhhdmUgc29tZSBxdWljayBj b21tZW50cyBhYm91dCB0aGUgZG9jdW1lbnQuPEJSPjxCUj5JIGRvbid0IHRoaW5rIExRSSBieSBp dHNlbGYgc2hvdWxkIGJlIHVzZWQuIExRSSBtdXN0IGJlIG1hdGNoZWQgd2l0aDxCUj5vdGhlciBp bmRpY2F0b3JzIHRvIG1ha2UgZ29vZCBkZWNpc2lvbnMuIExRSSBjYW4gYmUgYmFkIGZvciByb3V0 aW5nLjxCUj5TaW1pbGFybHksIHNob3J0ZXN0IHBhdGggY2FuIGJlIGJhZC48QlI+PEJSPkkgdGhp bmsgdGhhdCBvcGVyYXRpbmcgd2l0aCBsb3cgcm91dGluZyBzdGF0ZSBzaG91bGQgYmUgYW48QlI+ YWRkaXRpb25hbGx5IGdvYWwuIEZvciBleGFtcGxlLCBpZiBkZXZpY2VzIGhhdmUgb25seSAzMiBm b3J3YXJkaW5nPEJSPmVudHJpZXMgYXZhaWxhYmxlLiBUaGlzIGZhY3QgY291bGQgcHJvYmFibHkg YmUgY2FwdHVyZWQgaW4gb25lIG9mIHRoZTxCUj5leGlzdGluZyBzZWN0aW9ucy48QlI+PEJSPlJl Z2FyZGluZyB0aGUgcmVxdWlyZW1lbnRzIHNlY3Rpb246PEJSPjxCUj5JIHRoaW5rIHRoYXQgUjIg aXMgYSBiYWQgcmVxdWlyZW1lbnQuIEkgd291bGQgaW5zdGVhZCBzYXkgdGhhdCByb3V0aW5nPEJS PnNob3VsZCBiZSBlZmZpY2llbnQuIEVmZmljaWVuY3kgY2FuIGJlIGRlZmluZWQgaW4gbWFueSB3 YXlzLiBUaGVyZTxCUj5taWdodCBiZSA2bG93cGFuIG5ldHdvcmtzIHdoZXJlIGFsbCBkZXZpY2Vz IGFyZSBwb3dlciBzbyBwb3dlciB1c2FnZTxCUj5pcyBub3QgaW1wb3J0YW50LiBBbHRlcm5hdGl2 ZWx5IHRoZXJlIG1pZ2h0IGJlIG5vZGVzIHRoYXQgY2hvb3NlIG5vdDxCUj50byBwYXJ0aWNpcGF0 ZSBldmVuIHRob3VnaCB0aGV5IGhhdmUgZW5lcmd5LiBJIHRoaW5rIHRoYXQgcmVxdWlyaW5nPEJS Pm1pbmltYWwgZW5lcmd5IHJvdXRpbmcgaXMgdG9vIGhhcnNoIGFuZCB1bnJlYWxpc3RpYy48QlI+ PEJSPlIzLiBJIHdvdWxkIHNheSB0aGF0IDZsb3dwYW4gd29ya3MgYmVsb3cgSVAuIFRoZXJlZm9y ZSw8QlI+aW50ZXJjb25uZWN0aW9uIGlzIG5vdCBzZWFtbGVzcyBidXQgYmVsb3cgSVAuIFNvbWUg ZGV2aWNlIHdpbGwgbmVlZCB0bzxCUj5icmlkZ2UgKFBBTiBjb29yZGluYXRvciBvciBnYXRld2F5 KSB0aGlzIGdhcC4gRm9yIGV4YW1wbGUsJm5ic3A7IFJGRCBlZGdlPEJSPmRldmljZXMgd2lsbCBs aWtlbHkgbm90IGluY2x1ZGUgdGhpcyBjYXBhYmlsaXR5LjxCUj48QlI+UjQuIEknbSBub3Qgc3Vy ZSB0aGF0IHJvdXRpbmcgbmVlZHMgdG8gYmUgYXdhcmUgb2Ygc2xlZXBpbmcgbm9kZXMuIFdlPEJS PmNvdWxkIHJldmVyc2UgdGhlIHJlcXVpcmVtZW50IGFuZCBzYXkgdGhhdCBzbGVlcGluZyBub2Rl cyBtdXN0IGJlPEJSPmF3YXJlIG9mIHJvdXRpbmcuIE9yIHdlIGNvdWxkIGNyZWF0ZSBhIHJvdXRp bmcgcHJvdG9jb2wgdGhhdCBzaG91bGQ8QlI+d29yayBpbmRlcGVuZGVudCBvZiB0aGUgc2xlZXAg c2NoZWR1bGUuIEZvciBleGFtcGxlLCBmbG9vZGluZy48QlI+PEJSPlI1LiBIb3cgZG8gd2UgbWVh c3VyZSBzaW1wbGljaXR5IGFuZCByb2J1c3RuZXNzPyBIb3cgbXVjaCBzaW1wbGljaXR5PEJSPmFu ZCByb2J1c3RuZXNzIGFyZSByZXF1aXJlZCBieSB0aGUgdmFyaW91cyA2bG93cGFuIHBsYXllcnM/ PEJSPjxCUj5SNi4gSG93IG1vYmlsZT8gSG93IGR5bmFtaWM/PEJSPjxCUj5SNy4gQXJlIHlvdSBy ZWZlcnJpbmcgdG8gSVB2NiBORCBvciByb3V0aW5nIChMMiBpbiB0aGlzIGNhc2UpPEJSPm5laWdo Ym9yKGhvb2QpIGRpc2NvdmVyeT88QlI+PEJSPlI5LiBXaGF0IGlzIHRoZSBzY2FsYWJpbGl0eSBy ZXF1aXJlbWVudD8gSG93IG1hbnkgbm9kZXMgJmFtcDsgYXQgd2hhdCBkZW5zaXR5PzxCUj48QlI+ UjEwLiBJcyBMMiAoV0VQIGxpa2UpIHNlY3VyaXR5IGVub3VnaD88QlI+PEJSPklhbjxCUj48QlI+ PEJSPk9uIDIvMjcvMDcsIERvbWluaWsgS2FzcGFyICZsdDtkb21pbmlrQGV0cmkucmUua3ImZ3Q7 IHdyb3RlOjxCUj4mZ3Q7IEhpIGFsbCw8QlI+Jmd0OzxCUj4mZ3Q7IEEgbmV3IEludGVybmV0LURy YWZ0IGhhcyBqdXN0IGJlZW4gc3VibWl0dGVkIHRvIGVtcGhhc2l6ZSB0aGUgaW1wb3J0YW5jZSBv ZjxCUj4mZ3Q7IG1lc2ggcm91dGluZyBpbiBMb1dQQU5zLiBJIGJlbGlldmUgdGhhdCB3ZWxsIHRo b3VnaHQtb3V0IG1lc2ggcm91dGluZyBpcyBhPEJSPiZndDsgdml0YWwgcHJlY29uZGl0aW9uIGZv ciBmdWxseSBmdW5jdGlvbmFsIExvV1BBTnMgYW5kIHNob3VsZCBiZSBkaXNjdXNzZWQgaW48QlI+ Jmd0OyBtb3JlIGRldGFpbCB3aXRoaW4gdGhlIDZsb3dwYW4gd29ya2luZyBncm91cC48QlI+Jmd0 OzxCUj4mZ3Q7IENvbW1lbnRzIGFyZSB3ZWxjb21lZCBmb3IgdGhlIEludGVybmV0LURyYWZ0IHRp dGxlZDo8QlI+Jmd0OyAiRGVzaWduIEdvYWxzIGFuZCBSZXF1aXJlbWVudHMgZm9yIDZMb1dQQU4g TWVzaCBSb3V0aW5nIjxCUj4mZ3Q7PEJSPiZndDsgQWJzdHJhY3Q6PEJSPiZndDsgVGhpcyBkb2N1 bWVudCBkZWZpbmVzIHRoZSBwcm9ibGVtIHN0YXRlbWVudCwgZGVzaWduIGdvYWxzLCBhbmQgcmVx dWlyZW1lbnRzPEJSPiZndDsgZm9yIG1lc2ggcm91dGluZyBpbiBsb3ctcG93ZXIgd2lyZWxlc3Mg cGVyc29uYWwgYXJlYSBuZXR3b3JrcyAoTG9XUEFOcykuPEJSPiZndDs8QlI+Jmd0OyBBIFVSTCBm b3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8QlI+Jmd0OyB3d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWRva2FzcGFyLTZsb3dwYW4tcm91dHJlcS0wMC50eHQ8QlI+Jmd0OzxCUj4m Z3Q7IEJlc3QgcmVnYXJkcyw8QlI+Jmd0OyBEb21pbmlrPEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7 PEJSPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 QlI+Jmd0OyA2bG93cGFuIG1haWxpbmcgbGlzdDxCUj4mZ3Q7IDZsb3dwYW5AaWV0Zi5vcmc8QlI+ Jmd0OyA8QSBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93 cGFuIiB0YXJnZXQ9X2JsYW5rPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv LzZsb3dwYW48L0E+PEJSPiZndDs8QlI+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPEJSPjZsb3dwYW4gbWFpbGluZyBsaXN0PEJSPjZsb3dwYW5AaWV0 Zi5vcmc8QlI+PEEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Nmxvd3BhbiIgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby82bG93cGFuPC9BPjxCUj48L0ZPTlQ+PC9QPjwvRElWPjwvRElWPjwvRElWPjxpbWcgc3R5 bGU9ImRpc3BsYXk6bm9uZSIgd2lkdGg9MCBoZWlnaHQ9MCBzcmM9Imh0dHA6Ly91bWFpbC5ldHJp LnJlLmtyL0V4dGVybmFsX1JlYWRDaGVjay5hc3B4P2VtYWlsPTZsb3dwYW5AbGlzdHMuaWV0Zi5v cmcmbmFtZT02bG93cGFuJTQwbGlzdHMuaWV0Zi5vcmcmZnJvbWVtYWlsPXFraW1AZXRyaS5yZS5r ciZtZXNzYWdlaWQ9JTNDMjhiZjA5YzctZTA5Yi00MWIyLWFiZTgtODk4OGNlN2U5OTQwQGV0cmku cmUua3IlM0UiPg== ------=_NextPart_000_BF6F_01C75D30.BEDB6090-- --===============1298037326== 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 --===============1298037326==-- From 6lowpan-bounces@ietf.org Fri Mar 02 11:15:32 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNAPs-00058L-Df; Fri, 02 Mar 2007 11:15:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNAPr-00058B-IN for 6lowpan@lists.ietf.org; Fri, 02 Mar 2007 11:15:31 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNAPp-0004CJ-84 for 6lowpan@lists.ietf.org; Fri, 02 Mar 2007 11:15:31 -0500 Received: by ug-out-1314.google.com with SMTP id k3so702421ugf for <6lowpan@lists.ietf.org>; Fri, 02 Mar 2007 08:15:28 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oHM0BVxxGV3yj6mmRCTA0kol2T2rc+9rU+hblqHtMn275F0efxQ5SudSPSL1tPfhSDoxUqGA6sVm6X2J7JfjOhJjya2liv4OvminOvR+79HdrTRkhLV5Jcsl28payrKNGCK3Tr5WpEw+gSrNCcuunCnXjTw4vbB9tKHxCU15i2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C02rSByvOVjg9ef+RI9sgz6wMM1vsWQTFx9oumDBEbWtG0by/RFIh+mBFk8XPWqThKNx9GrtKfpUyAa7aW1vPpOVJOiNix97x+cUh7KEPlKDmRMjijmuNozanY6YLjcm7sosU7SgOXGODYKk1DTqrLAS+JahNmDeIEvnPu4gdTg= Received: by 10.78.166.7 with SMTP id o7mr280905hue.1172852127929; Fri, 02 Mar 2007 08:15:27 -0800 (PST) Received: by 10.78.45.10 with HTTP; Fri, 2 Mar 2007 08:15:27 -0800 (PST) Message-ID: <374005f30703020815i66a5556dufe94995b66927599@mail.gmail.com> Date: Fri, 2 Mar 2007 08:15:27 -0800 From: "Ian Chakeres" To: "=?EUC-KR?B?sei/67/u?=" Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0195705794==" Errors-To: 6lowpan-bounces@ietf.org --===============0195705794== Content-Type: text/plain; charset=EUC-KR; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline VHdvIHF1aWNrIGNvbW1lbnRzIGlubGluZS4KCk9uIDMvMi8wNywgsei/67/uIDxxa2ltQGV0cmku cmUua3I+IHdyb3RlOgo+ID5JIGRvbid0IHRoaW5rIExRSSBieSBpdHNlbGYgc2hvdWxkIGJlIHVz ZWQuIExRSSBtdXN0IGJlIG1hdGNoZWQgd2l0aAo+ID5vdGhlciBpbmRpY2F0b3JzIHRvIG1ha2Ug Z29vZCBkZWNpc2lvbnMuCj4KPiBJIGFncmVlLiBCdXQsIGluIG15IG9waW5pb24sCj4gTFFJIGlz IGxpa2VseSB0byBiZSB0aGUgcHJpbWFyeSBrZXkuCj4gVGhlIHJlYXNvbiBpcyBzYXZpbmcgVENP LgoKTFFJIGlzIGdvb2QgZm9yIG1ha2luZyBzaW5nbGUgaG9wIGRlY2lzaW9ucywgYnV0IG11Y2gg bW9yZSBjb21wbGljYXRlZAp3aGVuIHdlIHRhbGsgYWJvdXQgIG11bHRpcGxlIGhvcHMgKHJvdXRp bmcpLgoKPHNuaXA+Cgo+ID5SZWdhcmRpbmcgdGhlIHJlcXVpcmVtZW50cyBzZWN0aW9uOgo+ID4K PiA+SSB0aGluayB0aGF0IFIyIGlzIGEgYmFkIHJlcXVpcmVtZW50LiBJIHdvdWxkIGluc3RlYWQg c2F5IHRoYXQgcm91dGluZwo+ID5zaG91bGQgYmUgZWZmaWNpZW50LiBFZmZpY2llbmN5IGNhbiBi ZSBkZWZpbmVkIGluIG1hbnkgd2F5cy4gVGhlcmUKPiA+bWlnaHQgYmUgNmxvd3BhbiBuZXR3b3Jr cyB3aGVyZSBhbGwgZGV2aWNlcyBhcmUgcG93ZXIgc28gcG93ZXIgdXNhZ2UKPiA+aXMgbm90IGlt cG9ydGFudC4gQWx0ZXJuYXRpdmVseSB0aGVyZSBtaWdodCBiZSBub2RlcyB0aGF0IGNob29zZSBu b3QKPiA+dG8gcGFydGljaXBhdGUgZXZlbiB0aG91Z2ggdGhleSBoYXZlIGVuZXJneS4gSSB0aGlu ayB0aGF0IHJlcXVpcmluZwo+ID5taW5pbWFsIGVuZXJneSByb3V0aW5nIGlzIHRvbyBoYXJzaCBh bmQgdW5yZWFsaXN0aWMuCj4KPiBJbiBteSBvcGluaW9uLAo+IG1vc3QgNmxvd3BhbiBkZXZpY2Vz IGFyZSBwb3dlcmVkIGJ5IGJhdHRlcnkgYW5kCj4gVGhlIGJhdHRlcnkgcG93ZXIgbXVzdCBiZSB0 aGUgd2Vha2VzdCBwb2ludCBpbiBidXNpbmVzcy4KPgo+IEFzIHRpbWUgZ29lcyBhZnRlciB3aXJl bGVzcyBkZXZpY2VzIGhhdmUgYmVlbiBpbnN0YWxsZWQsCj4gbWFuYWdlbWVudCBjb3N0LCBmb3Ig ZXhhbXBsZXMsIGJhdHRlcnkgY29zdCwgbGFib3IgY29zdCBmb3IKPiBiYXR0ZXJ5IGNoYW5nZSwg bWFpbnRlbmFuY2UgY29zdCwgcmVtb3RlIG1vbml0b3JpbmcgYW5kIG1hbmFnZW1lbnQKPiBjb3N0 LCBldGMuIHdpbGwgb3ZlcndoZWxtIGluc3RhbGxhdGlvbiBjb3N0Lgo+Cj4gTWluaW1hbCBlbmVy Z3kgdXNhZ2UgaXMgd29ydGggYWRvcHRpbmcgZm9yIHJlcXVpcmVtZW50IHRvCj4gc2F2ZSBiYXR0 ZXJ5IGNvc3QgYW5kIHJlbGV2YW50IGxhYm9yIGNvc3QsIEkgdGhpbmsuCj4KPiAiaGFyc2ggYW5k IHVucmVhbGlzdGljIiBpcyBhIGdvb2QgZXhwcmVzc2lvbgo+IGJ1dCBzb2x2aW5nIGl0IG11c3Qg YmUgYSB0ZWNobmljYWwgdGFyZ2V0LgoKSSBndWVzcyBteSBjb21tZW50IGhhcyBtb3JlIHRvIGRv IHdpdGggaG93IHdlIHNvbHZlIHRoZSBwcm9ibGVtLiAgSQp0aGluayB0aGF0IGEgcm91dGluZyBw cm90b2NvbCB0aGF0IGNhbiBoYW5kbGUgc2xlZXBpbmcgbm9kZXMgKGFuZAphZGFwdCBxdWlja2x5 KSBhbmQgYWxzbyBvbmUgdGhhdCBjYW4gYmUgaW5mbHVlbmNlZCBieSBub2Rlcwp3aWxsaW5nbmVz cyAobWF5YmUgcmVtYWluaW5nIGJhdHRlcnkpIGlzIHN1ZmZpY2llbnQuIFRoZXJlZm9yZSwgSSdt Cm5vdCBzdXJlIHdlIG5lZWQgYW4gZW5lcmd5IGF3YXJlIHJvdXRpbmcgcHJvdG9jb2wuCg== --===============0195705794== 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 --===============0195705794==-- From 6lowpan-bounces@ietf.org Fri Mar 02 11:52:36 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNAzk-0005Ct-J1; Fri, 02 Mar 2007 11:52:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNAzj-0005Cb-CR for 6lowpan@lists.ietf.org; Fri, 02 Mar 2007 11:52:35 -0500 Received: from 66.237.74.130.ptr.us.xo.net ([66.237.74.130] helo=mail.dustnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNAzi-00013i-Nh for 6lowpan@lists.ietf.org; Fri, 02 Mar 2007 11:52:35 -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: RE: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements Date: Fri, 2 Mar 2007 08:52:34 -0800 Message-ID: <3D8BC6C339A9894C9955EF58D3722D659124E6@dust-exch-02.dusthq.dust-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements Thread-Index: AcdcnY5Wix4rCmYDRdOMH4bPo4c6XgASrXkg From: "Kris Pister" To: "Dominik Kaspar" X-Spam-Score: 0.1 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: 6lowpan@lists.ietf.org, manet@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 I would like to caution against designing the mesh routing protocols from the top down, without paying careful attention to what the MAC sub-layer will look like. In principle, from a strict layer-separationist perspective, it shouldn't matter. In practice, when some devices will be running at 100% duty cycle, and (most?) others will be constrained to run at 0.1% duty cycle, it makes all the difference. LQI is certainly important, but 1000x difference in available bandwidth on different links is even more important, and *must* drive the design of higher layers if they are to be efficient. We have seen the results of traditional networking applied to this new class of hardware platform, and they are entertaining, academically interesting, and commercially disastrous. I'm a newbie to IETF, so forgive me if I'm missing some key information, but as I see it we have come up with a reasonable format for IPv6 over 15.4 when the radios are on. The next step should be to figure out when the radios turn on, how they avoid interference, how they learn/announce/enforce their duty cycles, etc. Once that's done, or at least roughed out, then a rational discussion of routing can take place. ksjp Kristofer S.J.Pister Prof. EECS, UC Berkeley Founder & CTO, Dust Networks -----Original Message----- From: Dominik Kaspar [mailto:dominik@etri.re.kr]=20 Sent: Thursday, March 01, 2007 11:34 PM To: Ian Chakeres Cc: 6lowpan@lists.ietf.org; manet@ietf.org Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements Ian, all, Ian, thanks a lot for your fast reply and detailed commenting on the=20 "6LoWPAN Mesh Routing Requirements" draft=20 [http://www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.t xt].=20 I'm taking the right to post this answer to both the 6lowpan and MANET=20 working groups, as MANET folks might be interested in this discussion as well. Ian, I find your inputs very reasonable, but they made me feel that the term=20 "6lowpan" is not yet defined precisely enough to set up a strict set of=20 6lowpan routing requirements. For example, you give me the scenario of a 6lowpan network, in which all devices are powered and power usage is not important. But if I read the "6lowpan Problem Statement"=20 [http://tools.ietf.org/wg/6lowpan/draft-ietf-6lowpan-problem], I'm not sure=20 if such a set-up could still be called a 6lowpan, because that document=20 explains that in a LoWPAN "typically, some or all devices are battery=20 operated." This draft's intention is to provide the primary design goals of 6lowpan mesh routing and to stimulate responses for defining a set of requirements.=20 The requirements I listed are still as vague as the term "6lowpan" itself,=20 not at all proven and not fixed yet. I will keep all of your detailed=20 comments on the requirements in mind for a next revision. Also, it has=20 already been my intention to include a Section about what exactly the=20 differences are between routing in a MANET and in a LoWPAN. Best regards, Dominik ----- Original Message -----=20 From: "Ian Chakeres" To: "Dominik Kaspar" Cc: <6lowpan@lists.ietf.org> Sent: Thursday, March 01, 2007 2:00 AM Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements > > Good to see some requirements for 6lowpan routing. > > Personally, I'd like to know what can't be done with MANET protocols > and why. Hopefully, a future version will include this information. If > you have any comments please send them to me or the MANET list. > > Ian > > I have some quick comments about the document. > > I don't think LQI by itself should be used. LQI must be matched with > other indicators to make good decisions. LQI can be bad for routing. > Similarly, shortest path can be bad. > > I think that operating with low routing state should be an > additionally goal. For example, if devices have only 32 forwarding > entries available. This fact could probably be captured in one of the > existing sections. > > Regarding the requirements section: > > I think that R2 is a bad requirement. I would instead say that routing > should be efficient. Efficiency can be defined in many ways. There > might be 6lowpan networks where all devices are power so power usage > is not important. Alternatively there might be nodes that choose not > to participate even though they have energy. I think that requiring > minimal energy routing is too harsh and unrealistic. > > R3. I would say that 6lowpan works below IP. Therefore, > interconnection is not seamless but below IP. Some device will need to > bridge (PAN coordinator or gateway) this gap. For example, RFD edge > devices will likely not include this capability. > > R4. I'm not sure that routing needs to be aware of sleeping nodes. We > could reverse the requirement and say that sleeping nodes must be > aware of routing. Or we could create a routing protocol that should > work independent of the sleep schedule. For example, flooding. > > R5. How do we measure simplicity and robustness? How much simplicity > and robustness are required by the various 6lowpan players? > > R6. How mobile? How dynamic? > > R7. Are you referring to IPv6 ND or routing (L2 in this case) > neighbor(hood) discovery? > > R9. What is the scalability requirement? How many nodes & at what density? > > R10. Is L2 (WEP like) security enough? > > Ian > > > On 2/27/07, Dominik Kaspar wrote: >> Hi all, >> >> A new Internet-Draft has just been submitted to emphasize the importance=20 >> of >> mesh routing in LoWPANs. I believe that well thought-out mesh routing is=20 >> a >> vital precondition for fully functional LoWPANs and should be discussed=20 >> in >> more detail within the 6lowpan working group. >> >> Comments are welcomed for the Internet-Draft titled: >> "Design Goals and Requirements for 6LoWPAN Mesh Routing" >> >> Abstract: >> This document defines the problem statement, design goals, and=20 >> requirements >> for mesh routing in low-power wireless personal area networks (LoWPANs). >> >> A URL for this Internet-Draft is: >> www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.txt >> >> Best regards, >> Dominik >> >> >> >> _______________________________________________ >> 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Mar 02 15:51:01 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNEiN-0001iN-4y; Fri, 02 Mar 2007 15:50:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNEha-0000TS-4w for 6lowpan@lists.ietf.org; Fri, 02 Mar 2007 15:50:06 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNEhY-0001Rn-MX for 6lowpan@lists.ietf.org; Fri, 02 Mar 2007 15:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7FB5E329F4; Fri, 2 Mar 2007 20:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HNEhY-0002Zn-CD; Fri, 02 Mar 2007 15:50:04 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 02 Mar 2007 15:50:04 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: 6lowpan@lists.ietf.org Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-format-11.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low power WPAN Working Group of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.15.4 Networks Author(s) : G. Montenegro, et al. Filename : draft-ietf-6lowpan-format-11.txt Pages : 31 Date : 2007-3-2 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-11.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-11.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-11.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: <2007-3-2144230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6lowpan-format-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6lowpan-format-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-2144230.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 Fri Mar 02 16:36:37 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNFKu-0000SX-Jy; Fri, 02 Mar 2007 16:30:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNEi3-0001JU-7S for 6lowpan@lists.ietf.org; Fri, 02 Mar 2007 15:50:35 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HNEi2-0003P3-UE for 6lowpan@lists.ietf.org; Fri, 02 Mar 2007 15:50:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A7A87176D1; Fri, 2 Mar 2007 20:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HNEhY-0002Zt-Dg; Fri, 02 Mar 2007 15:50:04 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 02 Mar 2007 15:50:04 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: 6lowpan@lists.ietf.org Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-problem-08.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low power WPAN Working Group of the IETF. Title : 6LoWPAN: Overview, Assumptions, Problem Statement and Goals Author(s) : N. Kushalnagar, et al. Filename : draft-ietf-6lowpan-problem-08.txt Pages : 13 Date : 2007-3-2 This document describes the assumptions, problem statement and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-6lowpan-problem-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-6lowpan-problem-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-2144404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6lowpan-problem-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6lowpan-problem-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-2144404.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 Sun Mar 04 18:56:45 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO0Z0-0004wf-Cu; Sun, 04 Mar 2007 18:56:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO0Yy-0004vZ-Rv for 6lowpan@lists.ietf.org; Sun, 04 Mar 2007 18:56:24 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO0Yw-0000Z8-FH for 6lowpan@lists.ietf.org; Sun, 04 Mar 2007 18:56:24 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l24NuId0015286; Sun, 4 Mar 2007 16:56:19 -0700 (MST) From: Geoff Mulligan To: Carsten Bormann Content-Type: text/plain Date: Sun, 04 Mar 2007 16:57:01 -0700 Message-Id: <1173052621.4869.103.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 6lowpan <6lowpan@lists.ietf.org> Subject: [6lowpan] Agenda for next meeting 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 We need to settle on an agenda for the upcoming meeting. I think that everything is progressing with our two drafts - Thanks to Gabriel for making the last minute editorial fixes. As I've mentioned on the list a number of times, we are finished with the items in our charter - but certainly not finished with the work to be done. If we are going to take on some new tasks we need to recharter for those. Here is the complete list of topics that have been suggested on this list (in no particular order): Neighbor Discovery and Secure Neighbor Discovery (proposed standard) Stateful header compression (informational) 6lowpan applications (informational) mesh routing (proposed standard) Security analysis (informational) bootstrapping mobility MIB definition service discovery scalable routing commissioning power saving schemes (beacons) Architecture document I see at least 2 very important topics that we need to finish - * Neighbor Discovery for 6lowpan * 6lowpan architecture document Additionally, we need to reach some consensus on: * Routing (scalable, mesh under, route over) * Security * bootstrapping/commissioning Since we already have a draft (expired) for ND we should seriously consider finishing this work. We are have a number of drafts (also expired) and one not expired on routing alternatives. I think that the main topic for the meeting is the rechartering, but I think that it is extremely important that we talk with the Manet group and understand if their work can apply to 6lowpans. This understanding though may be based on the network architecture that we are trying to build. This is why I think that we should start with defining the 6lowpan arch. Please provide input on this. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Mar 04 19:27:37 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO137-0005zh-Gz; Sun, 04 Mar 2007 19:27:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO135-0005zX-IM for 6lowpan@lists.ietf.org; Sun, 04 Mar 2007 19:27:31 -0500 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO134-0005Ch-9F for 6lowpan@lists.ietf.org; Sun, 04 Mar 2007 19:27:31 -0500 Received: by nf-out-0910.google.com with SMTP id l36so2047620nfa for <6lowpan@lists.ietf.org>; Sun, 04 Mar 2007 16:27:29 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BXeWi+sIavN14MmKHQ9BXWzPJxyL07YI3rSIMOyqeEIYMIe8L+2dugytm52qfemS5bzB6w8Vz2s/c/6x9La3W+MYvPHmdq8jBzB8iGTSeTvSmIwQQxTNsFVpWW7qpdLRyHayijOVVZQew485W8dbVT0jlbIErWJdRDTIvx9sQyo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qIUlj84GNcQB2pQoGxreuyZoc1Nrge8zd5ATO/dK9AmFqoAXHDct/YMI7FyCzHKMzJniyqBiHgtqmMh4xfGpIzrbs4jKSa6y7StYyfepV2DqOW/u96PsNaUskIFeJfcLu1xI0/M+tbqtts9QZPcUfgwZl+t4QJNRV9txa422LIM= Received: by 10.82.114.3 with SMTP id m3mr4329997buc.1173054449526; Sun, 04 Mar 2007 16:27:29 -0800 (PST) Received: by 10.82.182.11 with HTTP; Sun, 4 Mar 2007 16:27:29 -0800 (PST) Message-ID: <43b91d370703041627y427721e3j8fbca99db046d152@mail.gmail.com> Date: Sun, 4 Mar 2007 16:27:29 -0800 From: "Samita Chakrabarti" To: "Geoff Mulligan" Subject: Re: [6lowpan] Agenda for next meeting In-Reply-To: <1173052621.4869.103.camel@dellx1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1173052621.4869.103.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 6lowpan <6lowpan@lists.ietf.org>, Carsten Bormann X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Geoff, On 3/4/07, Geoff Mulligan wrote: > We need to settle on an agenda for the upcoming meeting. I think that > everything is progressing with our two drafts - Thanks to Gabriel for > making the last minute editorial fixes. > Great! > Since we already have a draft (expired) for ND we should seriously > consider finishing this work. > Agree. I am submitting the updated version of ND draft before the cut-off date. Also submitting the updated version of lowpan-mobility requirement draft for a reference point of discussion. > I think that the main topic for the meeting is the rechartering, but I > think that it is extremely important that we talk with the Manet group > and understand if their work can apply to 6lowpans. > > This understanding though may be based on the network architecture that > we are trying to build. This is why I think that we should start with > defining the 6lowpan arch. 6lowpan architecture document is needed. Currently ND draft has some assumption about the topology and architecture of 6lowpan. We can start from there. Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Mar 04 20:10:05 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO1iB-0007Q5-16; Sun, 04 Mar 2007 20:09:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO1iA-0007Q0-2j for 6lowpan@lists.ietf.org; Sun, 04 Mar 2007 20:09:58 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO1i5-0001hv-Ko for 6lowpan@lists.ietf.org; Sun, 04 Mar 2007 20:09:58 -0500 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JEE000TOOKGA5@mailout2.samsung.com> for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 10:09:52 +0900 (KST) Received: from daniel ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JEE00MNSOKFXU@mmp2.samsung.com> for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 10:09:52 +0900 (KST) Date: Mon, 05 Mar 2007 10:09:44 +0900 From: Daniel Park Subject: RE: [6lowpan] Agenda for next meeting In-reply-to: <1173052621.4869.103.camel@dellx1> To: 'Geoff Mulligan' , 'Carsten Bormann' Message-id: <0JEE00MNUOKFXU@mmp2.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdeuTx6KSYcA53sSsWLZMjAVGT2oAABfExQ X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: '6lowpan' <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org inline... > Here is the complete list of topics that have been suggested > on this list (in no particular order): > > Neighbor Discovery and Secure Neighbor Discovery (proposed > standard) Stateful header compression (informational) 6lowpan > applications (informational) mesh routing (proposed standard) > Security analysis (informational) bootstrapping mobility MIB > definition service discovery scalable routing commissioning > power saving schemes (beacons) Architecture document For group's information here: * Routing http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-hilow-hierarchical- routing-01.txt http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-load-adhoc-routing- 01.txt http://daniel.vsix.net/ietf/6lowpan/draft-montenegro-6lowpan-dymo-low-routin g-02.txt *Security http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-security-analysis-0 2.txt * Service Discovery http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-sslp-01.txt * MIB http://daniel.vsix.net/ietf/6lowpan/draft-daniel-lowpan-mib-00.txt > I see at least 2 very important topics that we need to finish - > * Neighbor Discovery for 6lowpan > * 6lowpan architecture document > > Additionally, we need to reach some consensus on: > * Routing (scalable, mesh under, route over) > * Security > * bootstrapping/commissioning > > Since we already have a draft (expired) for ND we should > seriously consider finishing this work. We are have a number > of drafts (also > expired) and one not expired on routing alternatives. > > I think that the main topic for the meeting is the > rechartering, but I think that it is extremely important that > we talk with the Manet group and understand if their work can > apply to 6lowpans. > > This understanding though may be based on the network > architecture that we are trying to build. This is why I > think that we should start with defining the 6lowpan arch. sounds like ZB network architecture ? Daniel _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 05 00:19:40 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO5bX-0007l8-P1; Mon, 05 Mar 2007 00:19:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO5bV-0007ji-SH for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 00:19:21 -0500 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO5bT-00081D-BO for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 00:19:21 -0500 Received: by an-out-0708.google.com with SMTP id c18so1368134anc for <6lowpan@lists.ietf.org>; Sun, 04 Mar 2007 21:19:19 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ezegRJiGuxG6h0gPfpAKB2vMAe14illazzAQepL8rnNQqaDZkGF90vghnEvq4q5XMeiIzVNImhF37mrMAQnlnJVwI9Uk7PzdDYpYG0iJ4wGLcosy4ibuSqr1fRdId42GGjYF4IfKiYV44eJOQGG1fxqpqdxqe0CohF6Fol4fo9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Bge7Okhl7E7yxMZfr0WFlSC+nyL/V9IYxKtrdR7LBcFf07yyBL8luslefhnDA+bb6fnPLLHV/L+RjqdRIiLyUgzmNX8NoN+VLPh79pKGkWBnecpuZbhQg7UW/oyvXN4ZwG3jvKo9718GPlhodfIAG4WW4f1pnyn/PZcFrL+cC4Y= Received: by 10.114.200.2 with SMTP id x2mr1122072waf.1173071958384; Sun, 04 Mar 2007 21:19:18 -0800 (PST) Received: from ?129.254.112.125? ( [129.254.112.125]) by mx.google.com with ESMTP id m26sm15473777pof.2007.03.04.21.19.16; Sun, 04 Mar 2007 21:19:17 -0800 (PST) Message-ID: <45EBA851.7050900@gmail.com> Date: Mon, 05 Mar 2007 14:19:13 +0900 From: Myung-Ki Shin Organization: ETRI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoff Mulligan Subject: Re: [6lowpan] Agenda for next meeting References: <1173052621.4869.103.camel@dellx1> In-Reply-To: <1173052621.4869.103.camel@dellx1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 6lowpan <6lowpan@lists.ietf.org>, Carsten Bormann X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: myungki.shin@gmail.com 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 Geoff, thanks for your efforts, I think this is a very good idea. First of all, architecture work is most important here, since there 6lowpan architecture is not yet defined precisely enough (e.g, how dynamic, how mobile, how secure, how many nodes and what at density ?, etc. ) to take on new tasks below. Most new tasks seem to be dependent on how to define the 6lowpan architecture, I guess. So, I'd like to suggest we need to define 6lowpan architecture first, including design goals and requrements for each new task. I also think it is important that we talk with the MANET WG and know if their work can apply to 6lowpans and what can't be done with MANET protocols. Regards, Myung-Ki, Geoff Mulligan wrote: > We need to settle on an agenda for the upcoming meeting. I think that > everything is progressing with our two drafts - Thanks to Gabriel for > making the last minute editorial fixes. > > As I've mentioned on the list a number of times, we are finished with > the items in our charter - but certainly not finished with the work to > be done. If we are going to take on some new tasks we need to recharter > for those. > > Here is the complete list of topics that have been suggested on this > list (in no particular order): > > Neighbor Discovery and Secure Neighbor Discovery (proposed standard) > Stateful header compression (informational) > 6lowpan applications (informational) > mesh routing (proposed standard) > Security analysis (informational) > bootstrapping > mobility > MIB definition > service discovery > scalable routing > commissioning > power saving schemes (beacons) > Architecture document > > > I see at least 2 very important topics that we need to finish - > * Neighbor Discovery for 6lowpan > * 6lowpan architecture document > > Additionally, we need to reach some consensus on: > * Routing (scalable, mesh under, route over) > * Security > * bootstrapping/commissioning > > Since we already have a draft (expired) for ND we should seriously > consider finishing this work. We are have a number of drafts (also > expired) and one not expired on routing alternatives. > > I think that the main topic for the meeting is the rechartering, but I > think that it is extremely important that we talk with the Manet group > and understand if their work can apply to 6lowpans. > > This understanding though may be based on the network architecture that > we are trying to build. This is why I think that we should start with > defining the 6lowpan arch. > > Please provide input on this. > > geoff > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 05 03:17:10 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO8NQ-0004Ew-DP; Mon, 05 Mar 2007 03:17:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO8NP-0004Ej-KG for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 03:16:59 -0500 Received: from email2.etri.re.kr ([129.254.16.132] helo=email2.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO8NM-0002ZY-N4 for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 03:16:59 -0500 Received: from mail pickup service by email2.etri.info with Microsoft SMTPSVC; Mon, 5 Mar 2007 17:21:42 +0900 Priority: normal Thread-Topic: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements thread-index: Acde/05CgVzgI3ogRIK7Mfs/tlygbg== From: "Eunsook Kim" To: "Kris Pister" , "Dominik Kaspar" Bcc: Subject: RE: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements Date: Mon, 5 Mar 2007 17:21:42 +0900 Comment: GQ19@|@ZEk=E?,18?x, Bw<<4k@NEM3] G%AX?,18F@, 4c4g Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 X-OriginalArrivalTime: 05 Mar 2007 08:21:42.0869 (UTC) FILETIME=[4E6B8850:01C75EFF] X-Spam-Score: 0.7 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: 6lowpan@lists.ietf.org, manet@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eunsook Kim 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 Kris, Ian, The "6LoWPAN Mesh Routing Requirements" draft [http://www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.txt] was written based on cautioning against some discussion of designing routing protocols for 6lowpan. We think the first step is to mull over the differences from manet work, from the routing perspective. I think it is very important to clarify of the design goals and requirements of 6lowpan routing, before discussing detail solution space. In this point of view, I'm happy to see your comments and consideration of this work. I don't think we are ready to build up specification of 6lowpan routing protocols when we are not sure how much we can use Manet protocols; if 6lowpan may use 100% of pure manet protocols or may need major changes of them. That's why I would like to suggest to take some time to think of our goals and requirement in routing. The current version of the "6LoWPAN Mesh Routing Requirements" draft doesn't fill up the chapter 5, "Analysis of Existing Mesh Routing Candidates". I think this is important job to do in 6lowpan. We will see if we really need to define 6lowpan routing protocols or not. If we find the answer that we can use manet works, we don't need to consider seperate routing solution. I wish we could have nice discussion about more of fundamental points of 6lowpan routing in this meeting, instead of details. - eunsook ---------- From: "Kris Pister" >From Date: 2007-03-03 ?? 1:52:34 To: "Dominik Kaspar" Cc: "6lowpan@lists.ietf.org" <6lowpan@lists.ietf.org>, "manet@ietf.org" Subject: RE: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements I would like to caution against designing the mesh routing protocols from the top down, without paying careful attention to what the MAC sub-layer will look like. In principle, from a strict layer-separationist perspective, it shouldn't matter. In practice, when some devices will be running at 100% duty cycle, and (most?) others will be constrained to run at 0.1% duty cycle, it makes all the difference. LQI is certainly important, but 1000x difference in available bandwidth on different links is even more important, and *must* drive the design of higher layers if they are to be efficient. We have seen the results of traditional networking applied to this new class of hardware platform, and they are entertaining, academically interesting, and commercially disastrous. I'm a newbie to IETF, so forgive me if I'm missing some key information, but as I see it we have come up with a reasonable format for IPv6 over 15.4 when the radios are on. The next step should be to figure out when the radios turn on, how they avoid interference, how they learn/announce/enforce their duty cycles, etc. Once that's done, or at least roughed out, then a rational discussion of routing can take place. ksjp Kristofer S.J.Pister Prof. EECS, UC Berkeley Founder & CTO, Dust Networks -----Original Message----- From: Dominik Kaspar [mailto:dominik@etri.re.kr] Sent: Thursday, March 01, 2007 11:34 PM To: Ian Chakeres Cc: 6lowpan@lists.ietf.org; manet@ietf.org Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements Ian, all, Ian, thanks a lot for your fast reply and detailed commenting on the "6LoWPAN Mesh Routing Requirements" draft [http://www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.t xt]. I'm taking the right to post this answer to both the 6lowpan and MANET working groups, as MANET folks might be interested in this discussion as well. Ian, I find your inputs very reasonable, but they made me feel that the term "6lowpan" is not yet defined precisely enough to set up a strict set of 6lowpan routing requirements. For example, you give me the scenario of a 6lowpan network, in which all devices are powered and power usage is not important. But if I read the "6lowpan Problem Statement" [http://tools.ietf.org/wg/6lowpan/draft-ietf-6lowpan-problem], I'm not sure if such a set-up could still be called a 6lowpan, because that document explains that in a LoWPAN "typically, some or all devices are battery operated." This draft's intention is to provide the primary design goals of 6lowpan mesh routing and to stimulate responses for defining a set of requirements. The requirements I listed are still as vague as the term "6lowpan" itself, not at all proven and not fixed yet. I will keep all of your detailed comments on the requirements in mind for a next revision. Also, it has already been my intention to include a Section about what exactly the differences are between routing in a MANET and in a LoWPAN. Best regards, Dominik ----- Original Message ----- From: "Ian Chakeres" To: "Dominik Kaspar" Cc: <6lowpan@lists.ietf.org> Sent: Thursday, March 01, 2007 2:00 AM Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements > > Good to see some requirements for 6lowpan routing. > > Personally, I'd like to know what can't be done with MANET protocols > and why. Hopefully, a future version will include this information. If > you have any comments please send them to me or the MANET list. > > Ian > > I have some quick comments about the document. > > I don't think LQI by itself should be used. LQI must be matched with > other indicators to make good decisions. LQI can be bad for routing. > Similarly, shortest path can be bad. > > I think that operating with low routing state should be an > additionally goal. For example, if devices have only 32 forwarding > entries available. This fact could probably be captured in one of the > existing sections. > > Regarding the requirements section: > > I think that R2 is a bad requirement. I would instead say that routing > should be efficient. Efficiency can be defined in many ways. There > might be 6lowpan networks where all devices are power so power usage > is not important. Alternatively there might be nodes that choose not > to participate even though they have energy. I think that requiring > minimal energy routing is too harsh and unrealistic. > > R3. I would say that 6lowpan works below IP. Therefore, > interconnection is not seamless but below IP. Some device will need to > bridge (PAN coordinator or gateway) this gap. For example, RFD edge > devices will likely not include this capability. > > R4. I'm not sure that routing needs to be aware of sleeping nodes. We > could reverse the requirement and say that sleeping nodes must be > aware of routing. Or we could create a routing protocol that should > work independent of the sleep schedule. For example, flooding. > > R5. How do we measure simplicity and robustness? How much simplicity > and robustness are required by the various 6lowpan players? > > R6. How mobile? How dynamic? > > R7. Are you referring to IPv6 ND or routing (L2 in this case) > neighbor(hood) discovery? > > R9. What is the scalability requirement? How many nodes & at what density? > > R10. Is L2 (WEP like) security enough? > > Ian > > > On 2/27/07, Dominik Kaspar wrote: >> Hi all, >> >> A new Internet-Draft has just been submitted to emphasize the importance >> of >> mesh routing in LoWPANs. I believe that well thought-out mesh routing is >> a >> vital precondition for fully functional LoWPANs and should be discussed >> in >> more detail within the 6lowpan working group. >> >> Comments are welcomed for the Internet-Draft titled: >> "Design Goals and Requirements for 6LoWPAN Mesh Routing" >> >> Abstract: >> This document defines the problem statement, design goals, and >> requirements >> for mesh routing in low-power wireless personal area networks (LoWPANs). >> >> A URL for this Internet-Draft is: >> www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.txt >> >> Best regards, >> Dominik >> >> >> >> _______________________________________________ >> 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 05 03:18:39 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO8Ow-0006Be-UT; Mon, 05 Mar 2007 03:18:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO8Ov-0006BT-Cu for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 03:18:33 -0500 Received: from email2.etri.re.kr ([129.254.16.132] helo=email2.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO8Ot-0003LK-W7 for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 03:18:33 -0500 Received: from mail pickup service by email2.etri.info with Microsoft SMTPSVC; Mon, 5 Mar 2007 17:23:19 +0900 Priority: normal Thread-Topic: [6lowpan] Agenda for next meeting thread-index: Acde/4fiM8tN+o8KRXmhrAGxQfY4Hw== From: "Eunsook Kim" To: "Daniel Park" , "'Geoff Mulligan'" , "'Carsten Bormann'" Bcc: Subject: RE: [6lowpan] Agenda for next meeting Date: Mon, 5 Mar 2007 17:23:19 +0900 Comment: GQ19@|@ZEk=E?,18?x, Bw<<4k@NEM3] G%AX?,18F@, 4c4g Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 X-OriginalArrivalTime: 05 Mar 2007 08:23:19.0496 (UTC) FILETIME=[8803A480:01C75EFF] X-Spam-Score: 0.7 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: '6lowpan' <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eunsook Kim List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Folks, >For group's information here: >* Routing >http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-hilow-hierarchical- >routing-01.txt >http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-load-adhoc-routing- >01.txt >http://daniel.vsix.net/ietf/6lowpan/draft-montenegro-6lowpan-dymo-low-routin >g-02.txt > I have some concerns to discuss of details of routing for 6lowpan. As Geoff mentioned, 6lowpan needs to define its basic architecture first. Routing solution can be followed based on the space of the defining architecture. [http://www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.txt] describes the design goals and requirements of 6lowpan routing, and it suggests to do some analysis of existing mesh routing candidates. We could decide if we need details of routing solutions or not, based on the analysis. - eunsook _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 05 03:19:51 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO8QB-0007AC-BV; Mon, 05 Mar 2007 03:19:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO8QA-0007A3-5z for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 03:19:50 -0500 Received: from email2.etri.re.kr ([129.254.16.132] helo=email2.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO8Q8-0004nI-Q5 for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 03:19:50 -0500 Received: from mail pickup service by email2.etri.info with Microsoft SMTPSVC; Mon, 5 Mar 2007 17:24:36 +0900 Priority: normal Thread-Topic: [6lowpan] Agenda for next meeting thread-index: Acde/7YPpZDQvF9lQUmCtCKXMzBC9g== From: "Eunsook Kim" To: "Geoff Mulligan" , "Carsten Bormann" Bcc: Subject: RE: [6lowpan] Agenda for next meeting Date: Mon, 5 Mar 2007 17:24:36 +0900 Comment: GQ19@|@ZEk=E?,18?x, Bw<<4k@NEM3] G%AX?,18F@, 4c4g Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 X-OriginalArrivalTime: 05 Mar 2007 08:24:36.0967 (UTC) FILETIME=[B630C770:01C75EFF] X-Spam-Score: 0.7 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eunsook Kim 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 Geoff, >I think that the main topic for the meeting is the rechartering, but I >think that it is extremely important that we talk with the Manet group >and understand if their work can apply to 6lowpans. > >This understanding though may be based on the network architecture that >we are trying to build. This is why I think that we should start with >defining the 6lowpan arch. I have my two thumbs-up for your suggestion to start with defining the 6lowpan arch. While I have been approaching 6lowpan work from routing perspective, I strongly felt that we need architecture, framework, specific requirements for 6lowpan beforehand of all details. I would like to happily involve this work, if there is any space to fill up. :-) >Additionally, we need to reach some consensus on: > * Routing (scalable, mesh under, route over) > * Security > * bootstrapping/commissioning In terms of routing, I would like to suggest to have the same approach with Arch. work. We need to think more fundamental perspective for routing before going further to the details. Thanks, - eunsook _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 05 04:45:37 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO9kw-0006ro-EG; Mon, 05 Mar 2007 04:45:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO9kv-0006re-9h for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 04:45:21 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO9kt-0002g6-4Q for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 04:45:20 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2007 10:45:20 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l259jIUf010138; Mon, 5 Mar 2007 10:45:18 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l259iiBJ025158; Mon, 5 Mar 2007 09:45:05 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 10:44:53 +0100 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: RE: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements Date: Mon, 5 Mar 2007 10:44:47 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC039078E9@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements Thread-Index: Acde/05CgVzgI3ogRIK7Mfs/tlygbgAC1fIQ References: From: "Pascal Thubert \(pthubert\)" To: "Eunsook Kim" , "Kris Pister" , "Dominik Kaspar" X-OriginalArrivalTime: 05 Mar 2007 09:44:53.0918 (UTC) FILETIME=[ED512BE0:01C75F0A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9516; t=1173087918; x=1173951918; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[6lowpan]=20For=20comments=3A=206LoWPAN=20Mesh=20Rout ing=20Requirements |Sender:=20; bh=6Rz5a4nin//KaRdhZxnQfjgh8lpHqN9GcJdlnvdR39k=; b=eCfZLNuQIv12RmzrM+H8AVQckmhAaF03Tixg2z7qxSkhx4oKkpBpc3VBvXoNvXucpCuD5fMA 8WR7tS0/RLdXlMdRIWWwJyk8wz5gaTRKMMM/ZIzVWtQvigm1URMiCjYk; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: 6lowpan@lists.ietf.org, manet@ietf.org, manemo@mobileip.jp 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 Eunsook: >The current version of the "6LoWPAN Mesh Routing Requirements" draft doesn't fill up >the chapter 5, "Analysis of Existing Mesh Routing Candidates". Seems the people in the MANEMO Mailing List are very interested in participating to that analysis, so I copy the list. Pascal >-----Original Message----- >From: Eunsook Kim [mailto:eunah@etri.re.kr] >Sent: Monday, March 05, 2007 9:22 AM >To: Kris Pister; Dominik Kaspar >Cc: 6lowpan@lists.ietf.org; manet@ietf.org >Subject: RE: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements > >Kris, Ian, > >The "6LoWPAN Mesh Routing Requirements" draft >[http://www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00. txt] was written >based on cautioning against some discussion of designing routing protocols for 6lowpan. >We think the first step is to mull over the differences from manet work, from the routing >perspective. >I think it is very important to clarify of the design goals and requirements of 6lowpan routing, >before discussing detail solution space. > >In this point of view, I'm happy to see your comments and consideration of this work. >I don't think we are ready to build up specification of 6lowpan routing protocols >when we are not sure how much we can use Manet protocols; >if 6lowpan may use 100% of pure manet protocols or may need major changes of them. >That's why I would like to suggest to take some time to think of >our goals and requirement in routing. > >The current version of the "6LoWPAN Mesh Routing Requirements" draft doesn't fill up >the chapter 5, "Analysis of Existing Mesh Routing Candidates". >I think this is important job to do in 6lowpan. >We will see if we really need to define 6lowpan routing protocols or not. >If we find the answer that we can use manet works, we don't need to consider seperate routing >solution. > >I wish we could have nice discussion about more of fundamental points of 6lowpan routing in this >meeting, instead of details. > >- eunsook > >---------- >From: "Kris Pister" >>From Date: 2007-03-03 ?? 1:52:34 >To: "Dominik Kaspar" >Cc: "6lowpan@lists.ietf.org" <6lowpan@lists.ietf.org>, "manet@ietf.org" >Subject: RE: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements > > > > >I would like to caution against designing the mesh routing protocols >from the top down, without paying careful attention to what the MAC >sub-layer will look like. In principle, from a strict >layer-separationist perspective, it shouldn't matter. In practice, when >some devices will be running at 100% duty cycle, and (most?) others will >be constrained to run at 0.1% duty cycle, it makes all the difference. >LQI is certainly important, but 1000x difference in available bandwidth >on different links is even more important, and *must* drive the design >of higher layers if they are to be efficient. >We have seen the results of traditional networking applied to this new >class of hardware platform, and they are entertaining, academically >interesting, and commercially disastrous. >I'm a newbie to IETF, so forgive me if I'm missing some key information, >but as I see it we have come up with a reasonable format for IPv6 over >15.4 when the radios are on. The next step should be to figure out when >the radios turn on, how they avoid interference, how they >learn/announce/enforce their duty cycles, etc. Once that's done, or at >least roughed out, then a rational discussion of routing can take place. > >ksjp > >Kristofer S.J.Pister >Prof. EECS, UC Berkeley >Founder & CTO, Dust Networks > >-----Original Message----- >From: Dominik Kaspar [mailto:dominik@etri.re.kr] >Sent: Thursday, March 01, 2007 11:34 PM >To: Ian Chakeres >Cc: 6lowpan@lists.ietf.org; manet@ietf.org >Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements > >Ian, all, > > > >Ian, thanks a lot for your fast reply and detailed commenting on the >"6LoWPAN Mesh Routing Requirements" draft >[http://www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00. t >xt]. >I'm taking the right to post this answer to both the 6lowpan and MANET >working groups, as MANET folks might be interested in this discussion as > >well. > > > >Ian, I find your inputs very reasonable, but they made me feel that the >term >"6lowpan" is not yet defined precisely enough to set up a strict set of >6lowpan routing requirements. For example, you give me the scenario of a > >6lowpan network, in which all devices are powered and power usage is not > >important. But if I read the "6lowpan Problem Statement" >[http://tools.ietf.org/wg/6lowpan/draft-ietf-6lowpan-problem], I'm not >sure >if such a set-up could still be called a 6lowpan, because that document >explains that in a LoWPAN "typically, some or all devices are battery >operated." > > > >This draft's intention is to provide the primary design goals of 6lowpan > >mesh routing and to stimulate responses for defining a set of >requirements. >The requirements I listed are still as vague as the term "6lowpan" >itself, >not at all proven and not fixed yet. I will keep all of your detailed >comments on the requirements in mind for a next revision. Also, it has >already been my intention to include a Section about what exactly the >differences are between routing in a MANET and in a LoWPAN. > > > >Best regards, > >Dominik > > > > > >----- Original Message ----- >From: "Ian Chakeres" >To: "Dominik Kaspar" >Cc: <6lowpan@lists.ietf.org> >Sent: Thursday, March 01, 2007 2:00 AM >Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements > > >> >> Good to see some requirements for 6lowpan routing. >> >> Personally, I'd like to know what can't be done with MANET protocols >> and why. Hopefully, a future version will include this information. If >> you have any comments please send them to me or the MANET list. >> >> Ian >> >> I have some quick comments about the document. >> >> I don't think LQI by itself should be used. LQI must be matched with >> other indicators to make good decisions. LQI can be bad for routing. >> Similarly, shortest path can be bad. >> >> I think that operating with low routing state should be an >> additionally goal. For example, if devices have only 32 forwarding >> entries available. This fact could probably be captured in one of the >> existing sections. >> >> Regarding the requirements section: >> >> I think that R2 is a bad requirement. I would instead say that routing >> should be efficient. Efficiency can be defined in many ways. There >> might be 6lowpan networks where all devices are power so power usage >> is not important. Alternatively there might be nodes that choose not >> to participate even though they have energy. I think that requiring >> minimal energy routing is too harsh and unrealistic. >> >> R3. I would say that 6lowpan works below IP. Therefore, >> interconnection is not seamless but below IP. Some device will need to >> bridge (PAN coordinator or gateway) this gap. For example, RFD edge >> devices will likely not include this capability. >> >> R4. I'm not sure that routing needs to be aware of sleeping nodes. We >> could reverse the requirement and say that sleeping nodes must be >> aware of routing. Or we could create a routing protocol that should >> work independent of the sleep schedule. For example, flooding. >> >> R5. How do we measure simplicity and robustness? How much simplicity >> and robustness are required by the various 6lowpan players? >> >> R6. How mobile? How dynamic? >> >> R7. Are you referring to IPv6 ND or routing (L2 in this case) >> neighbor(hood) discovery? >> >> R9. What is the scalability requirement? How many nodes & at what >density? >> >> R10. Is L2 (WEP like) security enough? >> >> Ian >> >> >> On 2/27/07, Dominik Kaspar wrote: >>> Hi all, >>> >>> A new Internet-Draft has just been submitted to emphasize the >importance >>> of >>> mesh routing in LoWPANs. I believe that well thought-out mesh routing >is >>> a >>> vital precondition for fully functional LoWPANs and should be >discussed >>> in >>> more detail within the 6lowpan working group. >>> >>> Comments are welcomed for the Internet-Draft titled: >>> "Design Goals and Requirements for 6LoWPAN Mesh Routing" >>> >>> Abstract: >>> This document defines the problem statement, design goals, and >>> requirements >>> for mesh routing in low-power wireless personal area networks >(LoWPANs). >>> >>> A URL for this Internet-Draft is: >>> www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.txt >>> >>> Best regards, >>> Dominik >>> >>> >>> >>> _______________________________________________ >>> 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 > > > >_______________________________________________ >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 Mar 05 15:56:33 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOKEI-0008CV-BI; Mon, 05 Mar 2007 15:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOKDK-0006Or-Q2 for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 15:55:22 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOKD1-0001jz-TJ for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 15:55:22 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l25KswTx021952 for <6lowpan@lists.ietf.org>; Mon, 5 Mar 2007 13:55:03 -0700 (MST) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain Date: Mon, 05 Mar 2007 13:55:47 -0700 Message-Id: <1173128147.4869.169.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [6lowpan] 6lowpan rechartering X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org I've been talking with a few folks about this rechartering effort and how we are going to decide what tasks to take on next. I'd like to propose that we filter our opportunities / options based upon - What is it that is keeping us from demonstrating interoperability of 6lowpan devices? What do we need to tackle first so that we can show and build these interoperable networks? geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 05 17:22:41 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOLZf-00083i-Ed; Mon, 05 Mar 2007 17:22:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOKtY-0006mq-13 for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 16:39:00 -0500 Received: from neon.tcs.hut.fi ([130.233.215.20] helo=mail.tcs.hut.fi) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOKbW-0005N3-VH for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 16:21:00 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 5DCDB2C020BF9; Mon, 5 Mar 2007 23:20:19 +0200 (EET) Date: Mon, 5 Mar 2007 23:20:19 +0200 (EET) From: Wassim Haddad To: 6lowpan <6lowpan@lists.ietf.org> Subject: Re: [6lowpan] Agenda for next meeting In-Reply-To: <43b91d370703041627y427721e3j8fbca99db046d152@mail.gmail.com> Message-ID: References: <1173052621.4869.103.camel@dellx1> <43b91d370703041627y427721e3j8fbca99db046d152@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Carsten Bormann X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi, I'd like to point out the ongoing work on securing neighbor discovery (draft-haddad-mipshop-optisend-02). We're planning to submit an updated version to the 6lowpan WG once the new charter is approved. Comments appreciated. Regards, Wassim H. On Sun, 4 Mar 2007, Samita Chakrabarti wrote: > Hi Geoff, > > On 3/4/07, Geoff Mulligan wrote: > > We need to settle on an agenda for the upcoming meeting. I think that > > everything is progressing with our two drafts - Thanks to Gabriel for > > making the last minute editorial fixes. > > > > Great! > > > Since we already have a draft (expired) for ND we should seriously > > consider finishing this work. > > > Agree. > I am submitting the updated version of ND draft before the cut-off date. > > > Also submitting the updated version of lowpan-mobility requirement draft > for a reference point of discussion. > > > I think that the main topic for the meeting is the rechartering, but I > > think that it is extremely important that we talk with the Manet group > > and understand if their work can apply to 6lowpans. > > > > This understanding though may be based on the network architecture that > > we are trying to build. This is why I think that we should start with > > defining the 6lowpan arch. > > 6lowpan architecture document is needed. Currently ND draft has some > assumption about the topology and architecture of 6lowpan. We can start > from there. > > 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 Mar 05 18:57:54 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HON3i-0006qv-H2; Mon, 05 Mar 2007 18:57:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HON3g-0006qC-1W for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 18:57:36 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HON35-0006PJ-GW for 6lowpan@lists.ietf.org; Mon, 05 Mar 2007 18:57:35 -0500 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 <0JEG00EX7FUKCJ@mailout1.samsung.com> for 6lowpan@lists.ietf.org; Tue, 06 Mar 2007 08:56:44 +0900 (KST) Received: from daniel ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JEG005QZFUK3L@mmp2.samsung.com> for 6lowpan@lists.ietf.org; Tue, 06 Mar 2007 08:56:44 +0900 (KST) Date: Tue, 06 Mar 2007 08:56:35 +0900 From: Daniel Park Subject: RE: [6lowpan] Agenda for next meeting In-reply-to: To: 'Wassim Haddad' , '6lowpan' <6lowpan@lists.ietf.org> Message-id: <0JEG005R0FUK3L@mmp2.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdfdOXSsFA7NKydQySGUePp/FzuRQACjcww X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: 'Carsten Bormann' X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Wassim, Glad to see your activities in this space...:-) I am digging SeND relevant text from the security-analysis draft: http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-security-analysis-0 2.txt if NDP (Neighbor Discovery Protocol) is applied to 6lowpan, SeND (Secure Neighbor Discovery) should be considered to provide security in conjunction with neighbor discovery protocol. So far, CGA (Cryptographically Generated Addresses) [RFC3972] and SeND options [RFC3971] are newly designed by IETF and it works well over existing IP networks. However, CGA seems very complex to be applied to 6lowpan networks. Furthermore, SeND options requires huge additional options (i.e., CGA option, RSA Signature option, Timestamp and Nonce option and etc.) which increase the packet size accordingly. Thus it is doubtful if Secure Neighbor Discovery protocol could be directly applicable to 6lowpan networks without any optimization. We need further in-depth discussion here. Are you thinking SeND can be applied for 6lowpan networks ? How much fatting down SeND itself ? It seems interesting issue but also really difficult aspect at the same time from the security point of view. Anyhow, I will go through your draft and get back to you with more details soon. Also your comments are highly welcome. Daniel > -----Original Message----- > From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] > Sent: Tuesday, March 06, 2007 6:20 AM > To: 6lowpan > Cc: Carsten Bormann > Subject: Re: [6lowpan] Agenda for next meeting > > Hi, > > I'd like to point out the ongoing work on securing neighbor > discovery (draft-haddad-mipshop-optisend-02). We're planning > to submit an updated version to the 6lowpan WG once the new > charter is approved. > > Comments appreciated. > > > Regards, > > Wassim H. > > > > On Sun, 4 Mar 2007, Samita Chakrabarti wrote: > > > Hi Geoff, > > > > On 3/4/07, Geoff Mulligan wrote: > > > We need to settle on an agenda for the upcoming meeting. I think > > > that everything is progressing with our two drafts - Thanks to > > > Gabriel for making the last minute editorial fixes. > > > > > > > Great! > > > > > Since we already have a draft (expired) for ND we should > seriously > > > consider finishing this work. > > > > > Agree. > > I am submitting the updated version of ND draft before the > cut-off date. > > > > > > Also submitting the updated version of lowpan-mobility requirement > > draft for a reference point of discussion. > > > > > I think that the main topic for the meeting is the > rechartering, but > > > I think that it is extremely important that we talk with > the Manet > > > group and understand if their work can apply to 6lowpans. > > > > > > This understanding though may be based on the network > architecture > > > that we are trying to build. This is why I think that we should > > > start with defining the 6lowpan arch. > > > > 6lowpan architecture document is needed. Currently ND draft > has some > > assumption about the topology and architecture of 6lowpan. We can > > start from there. > > > > 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 > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 06 07:33:45 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOYrD-0001LF-H6; Tue, 06 Mar 2007 07:33:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOYrB-0001L9-Qo for 6lowpan@lists.ietf.org; Tue, 06 Mar 2007 07:33:29 -0500 Received: from relay2.ptmail.sapo.pt ([212.55.154.22] helo=sapo.pt) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HOYr8-0005X9-7U for 6lowpan@lists.ietf.org; Tue, 06 Mar 2007 07:33:29 -0500 Received: (qmail 3936 invoked from network); 6 Mar 2007 12:32:59 -0000 Received: from unknown (HELO sapo.pt) (10.134.35.209) by relay2 with SMTP; 6 Mar 2007 12:32:59 -0000 Received: (qmail 10544 invoked from network); 6 Mar 2007 12:32:59 -0000 X-AntiVirus: PTMail-AV 0.3-0.90.0 X-Virus-Status: Clean (0.03810 seconds) Received: from unknown (HELO [192.168.1.10]) (tandre@sapo.pt@[85.240.136.52]) (envelope-sender ) by mta14 (qmail-ldap-1.03) with SMTP for ; 6 Mar 2007 12:32:59 -0000 Message-ID: <45ED5F81.3020304@dei.uc.pt> Date: Tue, 06 Mar 2007 12:33:05 +0000 From: Tiago Camilo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Eunsook Kim Subject: Re: [6lowpan] Agenda for next meeting References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 6lowpan <6lowpan@lists.ietf.org>, Carsten Bormann X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi, Eunsook Kim wrote > Geoff, > > >> I think that the main topic for the meeting is the rechartering, but I >> think that it is extremely important that we talk with the Manet group >> and understand if their work can apply to 6lowpans. >> >> This understanding though may be based on the network architecture that >> we are trying to build. This is why I think that we should start with >> defining the 6lowpan arch. >> > > I have my two thumbs-up for your suggestion to start with defining the 6lowpan arch. > While I have been approaching 6lowpan work from routing perspective, > I strongly felt that we need architecture, framework, specific requirements for 6lowpan beforehand of all details. > > I would like to happily involve this work, if there is any space to fill up. :-) > > I truly agree with the need to come up with a 6lowpan architecture, that became the basis of our working group. Such draft should address the topology, architecture and 6lowpan devices. Is important to understand how can mesh devices, from as small as 4K of flash and 100s of bytes of RAM up to devices full capable of routing, sensing and acting. Should we consider in adopting some kind of addressing functions for the smaller devices? or as Ron Strich stated: "Should we make it easy for these simple protocol implementations at this level to adapt to 6lowpan? If we want to include these small devices, should we consider a more constrained design (limited payload, P2P/star only) that would simplify the adaptation layer?" I think that in the near future 6lowpan networks will be a group of truly mesh devices, that will present different characteristics (i.e. power, memory and radio frequency) and therefore is important to create a stable 6lowpan framework, allowing the devices communication. As Eunsook Kim i also would like to be involve, if possible, in such definition. Tiago Camilo >> Additionally, we need to reach some consensus on: >> * Routing (scalable, mesh under, route over) >> * Security >> * bootstrapping/commissioning >> > > In terms of routing, I would like to suggest to have the same approach with Arch. work. > We need to think more fundamental perspective for routing before going further to the details. > > Thanks, > > - eunsook > > > > > _______________________________________________ > 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 Mar 06 11:50:00 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOcrG-0001F6-6Y; Tue, 06 Mar 2007 11:49:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOcrF-0001Ex-8b; Tue, 06 Mar 2007 11:49:49 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOcrD-0001pF-Nk; Tue, 06 Mar 2007 11:49:49 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l26GnXiI028651; Tue, 6 Mar 2007 09:49:35 -0700 (MST) From: Geoff Mulligan To: Pekka Savola , ietf@ietf.org, 6lowpan <6lowpan@lists.ietf.org> In-Reply-To: <45ED1BDC.80302@cisco.com> References: <45ED1BDC.80302@cisco.com> Content-Type: text/plain Date: Tue, 06 Mar 2007 09:50:27 -0700 Message-Id: <1173199828.4869.223.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: Mark Townsley , 6lowpan-chairs@tools.ietf.org Subject: [6lowpan] Re: [Fwd: Fwd: Re: Last Call: draft-ietf-6lowpan-problem (6LoWPAN: Overview, Assumptions, Problem Statement and Goals) to Informational RFC] 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 Pekka, You bring up some good points. I will attempt to clarify some of your questions. You question about switches does point to an overloaded term. In that particular paragraph the "switches" we are talking about are electrical switches, as in light switches, not network switches. We'll fix the wording. The reason we use the term personal area network is that it is the industry term used for 802.15.4 networks. I agree that these devices are not "personal", but it is a nomenclature that we are stuck with by the IEEE. We did not address the security of underlying mesh network because we have not yet defined that layer yet. We are working with MANET to define that and the security for the mesh would be addressed in that document. It was not germane to the format/adaptation header. To you question about network management - again this document is about the format and header encoding only. Network management and security will need to be addressed by a future 6lowpan management or 6lowpan ops document. We will look at the issues related to using header compression and ipsec. geoff On Tue, 2007-03-04, Pekka Savola wrote: > >Date: Sun, 4 Mar 2007 14:54:24 +0200 (EET) > >From: Pekka Savola > >To: ietf@ietf.org > >Cc: 6lowpan@lists.ietf.org > >Subject: Re: Last Call: draft-ietf-6lowpan-problem (6LoWPAN: Overview, > > Assumptions, Problem Statement and Goals) to Informational RFC > > > >On Thu, 15 Feb 2007, The IESG wrote: > >>The IESG has received a request from the IPv6 over Low power WPAN WG > >>(6lowpan) to consider the following document: > >> > >>- '6LoWPAN: Overview, Assumptions, Problem Statement and Goals ' > >> as an Informational RFC > >> > >>The IESG plans to make a decision in the next few weeks, and solicits > >>final comments on this action. Please send substantive comments to the > >>ietf@ietf.org mailing lists by 2007-03-01. Exceptionally, > >>comments may be sent to iesg@ietf.org instead. In either case, please > >>retain the beginning of the Subject line to allow automated sorting. > >> > >>The file can be obtained via > >>http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-07.txt > > > >Sorry for slightly missing the LC deadline. > > > > 6. Low cost. These devices are typically associated with sensors, > > switches, etc. This drives some of the other characteristics > > such as low processing, low memory, etc. Numerical values for > > "low" elided on purpose since costs tend to change over time. > > > >==> what kind of 'switch' do you have in mind? How does that > >participate in a _personal_ area network? > > > >As a side note, there appears to be nothing in the requirements that > >relates directly to the 'personal' of personal area network. For > >example, there are no assumptions about the maximum diameter of the network. > > > >Are you really specifying Low-power Wireless Area Networks rather > >than LoWPANs? Are there any goals, problems or assumptions relating > >to 'personal' that one should be aware of? Or should you just > >remove 'personal' from the text(s)? > > > >4.2. Topologies > > > >==> I was a bit disappointed as I saw no mention of securiry wrt > >routing in the mesh topology. It isn't mentioned in the later part > >of the text as well. E.g., how do you prevent malicious nodes from > >joining the network and doing e.g., MiTM attacks by posing as routers? > > > >Are you assuming that the link-layer security will keep unauthorized > >nodes away from the LoWPAN network? If that is the assumption, more > >emphasis might be needed on how to actually configure the link-layer > >keying. Based on current text it's not clear if configuring keying > >in all the nodes is operationally feasible or even possible. > > > >4.3. Limited Packet Size > > > > Applications within LoWPANs are expected to originate small packets. > > Adding all layers for IP connectivity should still allow transmission > > in one frame without incurring excessive fragmentation and > > reassembly. Furthermore, protocols must be designed or chosen so > > that the individual "control/protocol packets" fit within a single > > 802.15.4 frame. Along these lines, IPv6's requirement of sub-IP > > reassembly (see Section 5) may pose challenges for low-end LoWPAN > > devices that do not have enough RAM or storage for a 1280-octet > > packet. > > > >==> I wonder what the last sentence implies. Given that the -format > >specification still requires the 1280 byte IP MTU, the RAM > >requirement was probably not blocking here. Rewording this slightly > >due to how -format ended up being might be useful. > > > >4.4. Limited configuration and management > > > > As alluded to above, devices within LoWPANs are expected to be > > deployed in exceedingly large numbers. Additionally, they are > > expected to have limited display and input capabilities. > > Furthermore, the location of some of these devices may be hard to > > reach. Accordingly, protocols used in LoWPANs should have minimal > > configuration, preferably work "out of the box", be easy to > > bootstrap, and enable the network to self heal given the inherent > > unreliable characteristic of these devices. Network management > > should have little overhead yet be powerful enough to control dense > > deployment of devices. > > > >==> no or very little configuration, yet network management should > >be powerful enough to control a huge number of devices? How do you > >manage the authorization of network management then, i.e., who is > >allowed to control the devices? > > > >I'm somewhat surprised that you do not mention overcoming (initial) > >configuration tasks (including but not limited to network > >management) as an item under Section 5. > > > > For network layer security, two models are applicable: end-to-end > > security, e.g. using IPsec transport mode, or security that is > > limited to the wireless portion of the network, e.g. using a security > > gateway and IPsec tunnel mode. > > > >==> it might be useful to mention how header compression relates to > >IPsec. Are there problems if both are applied? If non-NULL IPsec > >transform is used, can header compression be used at all? > > > >-- > >Pekka Savola "You each name yourselves king, yet the > >Netcore Oy kingdom bleeds." > >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > >_______________________________________________ > >Ietf mailing list > >Ietf@ietf.org > >https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Mar 07 04:06:56 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOs6g-0001kx-2w; Wed, 07 Mar 2007 04:06:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOizL-0005ZM-3f for 6lowpan@lists.ietf.org; Tue, 06 Mar 2007 18:22:35 -0500 Received: from neon.tcs.hut.fi ([130.233.215.20] helo=mail.tcs.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOhb1-0008LF-Vo for 6lowpan@lists.ietf.org; Tue, 06 Mar 2007 16:53:25 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id D99072C020BE5; Tue, 6 Mar 2007 23:53:22 +0200 (EET) Date: Tue, 6 Mar 2007 23:53:22 +0200 (EET) From: Wassim Haddad To: Daniel Park Subject: RE: [6lowpan] Agenda for next meeting In-Reply-To: <0JEG005R0FUK3L@mmp2.samsung.com> Message-ID: References: <0JEG005R0FUK3L@mmp2.samsung.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: '6lowpan' <6lowpan@lists.ietf.org>, 'Carsten Bormann' X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Daniel, On Tue, 6 Mar 2007, Daniel Park wrote: > I am digging SeND relevant text from the security-analysis draft: > http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-security-analysis-0 > 2.txt > > if NDP (Neighbor Discovery Protocol) is applied to 6lowpan, SeND > (Secure Neighbor Discovery) should be considered to provide security > in conjunction with neighbor discovery protocol. So far, CGA > (Cryptographically Generated Addresses) [RFC3972] and SeND options > [RFC3971] are newly designed by IETF and it works well over existing > IP networks. However, CGA seems very complex to be applied to > 6lowpan networks. => Agree. That's why it needs to be replaced with a lighter but at least equally (if not better!) efficient mechanism and that's what OptiSEND aims to provide. > Furthermore, SeND options requires huge additional > options (i.e., CGA option, RSA Signature option, Timestamp and Nonce > option and etc.) which increase the packet size accordingly. Thus > it is doubtful if Secure Neighbor Discovery protocol could be > directly applicable to 6lowpan networks without any optimization. => Agree. > We need further in-depth discussion here. Are you thinking > SeND can be applied for 6lowpan networks ? How much fatting > down SeND itself? It seems interesting issue but also really > difficult aspect at the same time from the security point of view. => In few words (but more work is of course still needed), OptiSEND consists on using CGA *only* at the beginning (i.e., attachment). The CGA enables to derive a shared secret between the node and the AR, which will be used to authenticate all ND messages (i.e., which also means that all ND messages will go via the AR). One-way hash chain are suggested to authenticate multicast Router Advertisement messages... > Anyhow, I will go through your draft and get back to you with > more details soon. => Thanks a lot! Comments highly appreciated. Regards, Wassim H. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Mar 07 04:13:04 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsCl-0005FW-Vd; Wed, 07 Mar 2007 04:13:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOrLr-0005ZV-8h for 6lowpan@lists.ietf.org; Wed, 07 Mar 2007 03:18:23 -0500 Received: from email2.etri.re.kr ([129.254.16.132] helo=email2.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOrLp-0002bH-TI for 6lowpan@lists.ietf.org; Wed, 07 Mar 2007 03:18:23 -0500 Received: from mail pickup service by email2.etri.info with Microsoft SMTPSVC; Wed, 7 Mar 2007 17:23:06 +0900 Priority: normal Thread-Topic: [6lowpan] manet's open discussion thread-index: AcdgkdUMKlAZI7UmSGGtkwu6pIr3Lg== From: "Eunsook Kim" To: <6lowpan@lists.ietf.org> Bcc: Subject: [6lowpan] manet's open discussion Date: Wed, 7 Mar 2007 17:23:06 +0900 Comment: GQ19@|@ZEk=E?,18?x, Bw<<4k@NEM3] G%AX?,18F@, 4c4g Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 X-OriginalArrivalTime: 07 Mar 2007 08:23:06.0626 (UTC) FILETIME=[D52B5620:01C76091] X-Spam-Score: 0.7 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eunsook Kim 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, Many of you maybe already checked this, but want to share it for those who didn't have this info yet. MANET wg folks include 6lowpan issue in their open discussion. IMHO, it will be good to gather our opinion in 6lowpan and involve in MANET's open discussion. -eunsook -------- cut here ------------ IETF 68 MANET WG Agenda MANET Session 1 (2 hours) Wednesday, Afternoon Session I 1300-1500 Room Name: Anthens/Barcelona Prague, Czech Republic Agenda Bashing 5 min -blue sheets & state your name at the microphone WG Progress MANET IANA Needs -draft-ietf-manet-iana-00.txt Generalized Packet and Message Format Discussion -draft-ietf-manet-packetbb-04.txt MANET Neighborhood Discovery Protocol Discussion -draft-ietf-manet-nhdp-03.txt OLSRv2 Discussion -draft-ietf-manet-olsrv2-03.txt SMF Discussion -draft-ietf-manet-smf-04.txt DYMO Discussion -draft-ietf-manet-dymo-08.txt Jitter & Time TLV -draft-clausen-manet-jitter-01.txt -draft-clausen-manet-timetlv-00.txt Open Discussion, Related Work & Announcements -draft-ietf-autoconf-manetarch-01.txt Autoconf OSPF-MANET 6lowpan MANEMO _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Mar 07 04:13:41 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsDM-0006vh-V2; Wed, 07 Mar 2007 04:13:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOrp3-000502-RU; Wed, 07 Mar 2007 03:48:33 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOrp2-0003LG-C7; Wed, 07 Mar 2007 03:48:33 -0500 Received: from [199.233.92.21] (dev21.coslabs.com [199.233.92.21]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l278mMLi003912; Wed, 7 Mar 2007 01:48:22 -0700 (MST) From: Geoff Mulligan To: Pekka Savola In-Reply-To: References: <45ED1BDC.80302@cisco.com> <1173199828.4869.223.camel@dellx1> Content-Type: text/plain Date: Wed, 07 Mar 2007 01:49:22 -0700 Message-Id: <1173257362.4620.86.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Mark Townsley , 6lowpan <6lowpan@lists.ietf.org>, 6lowpan-chairs@tools.ietf.org, ietf@ietf.org Subject: [6lowpan] Re: [Fwd: Fwd: Re: Last Call: draft-ietf-6lowpan-problem (6LoWPAN: Overview, Assumptions, Problem Statement and Goals) to Informational RFC] 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 Wed, 2007-03-07 at 08:07 +0200, Pekka Savola wrote: > Hi, > > On Tue, 6 Mar 2007, Geoff Mulligan wrote: > > You question about switches does point to an overloaded term. In that > > particular paragraph the "switches" we are talking about are electrical > > switches, as in light switches, not network switches. We'll fix the > > wording. > > I guessed as much, which is what triggered me to wonder about the use > of the term 'personal' as I don't think an electrical switch is > typically carried in your PAN :-) > > > The reason we use the term personal area network is that it is the > > industry term used for 802.15.4 networks. I agree that these devices > > are not "personal", but it is a nomenclature that we are stuck with by > > the IEEE. > > If you don't want to drop 'Personal' from the used terminology, I > would suggest considering adding a sentence or two in Introduction of > all relevant documents to make it clearer that the IETF has designed a > generic solution which also applies outside of PANs. The IETF > specifications as far as I can see are not restricted to 'P' in 'PAN'. > (If you consider assumptions and possible security tradeoffs this may > have good and bad consequences.) I don't particularly like the term PAN applied to RF networks that are not "Personal" but we are using the term from the RF platform where we are directing these documents - IEEE 802.15.4 - "Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs)" and this is the relevant document that we did reference. While I might prefer to use the term "Premise Area Network" this would be confusing as it isn't the term used for 802.15.4 networks. > > > We did not address the security of underlying mesh network because we > > have not yet defined that layer yet. We are working with MANET to > > define that and the security for the mesh would be addressed in that > > document. It was not germane to the format/adaptation header. > > > > To you question about network management - again this document is about > > the format and header encoding only. Network management and security > > will need to be addressed by a future 6lowpan management or 6lowpan ops > > document. > > I'm not sure whether I agree. We're talking about a problem statement > draft. I'd agree that network management is probably outside the > scope of draft-ietf-6lowpan-format. It seemed that the network > management goals could not be fulfilled without compromising other > goals (easy or zero configuration), raising a doubt about the > feasibility of the goals. I don't agree. I think that we can build managed networks that also use "zero conf". I don't think that these two goals are at odds and that is why we put them in the problem statement, so we would be reminded that we need to build a solution that is manageable and still easy/simple to install. > > Even if NM doesn't need to be addressed in 6lowpan-format, I think > (operational) security should be. The key questions (IMHO) here are, > 'Are the security mechanisms specified by IEEE and IETF good enough > that using them is feasible in real life? Will they get used?' So > far, the document doesn't give me an assurance that the answer to > either is 'yes', and hence it leaves me little to use when trying to > figure out whether the security model of 6lowpan design is adequate, > and consequently, whether the IP specification is complete or not. I'm not sure if you are referring the to format document or the problem statement document here. From my understanding the problem statement document is not supposed to be defining the solutions - it isn't a standards doc and security mechanisms are outside the scope of format document since it is just defining a header encoding scheme to carry IP over 802.15.4 frames. It doesn't preclude the use of IPsec or some other yet to be defined security protocol. If there is a mesh network layered under 6lowpan that document will need to define the security used to protect the routing in the mesh. If we are discussing what devices may join a network that will need to be specified by the network management document. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 08 01:45:54 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPCNf-0001iZ-Ns; Thu, 08 Mar 2007 01:45:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPCNd-0001RQ-RA for 6lowpan@lists.ietf.org; Thu, 08 Mar 2007 01:45:37 -0500 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPCNc-0008S2-20 for 6lowpan@lists.ietf.org; Thu, 08 Mar 2007 01:45:37 -0500 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Thu, 8 Mar 2007 15:50:25 +0900 Priority: normal Thread-Topic: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements thread-index: AcdhTgxx/EGuza7aTZ2NMf9qomKQuA== From: "KIM Yong-Woon" To: "Ian Chakeres" Bcc: Subject: RE: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements Date: Thu, 8 Mar 2007 15:50:24 +0900 Comment: GQ19@|@ZEk=E?,18?x, Bw<<4k@NEM3] G%AX?,18F@, 4c4g Message-ID: <8bbe01c7614e$0c7a8d50$8310fe81@etri.info> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 X-OriginalArrivalTime: 08 Mar 2007 06:50:25.0009 (UTC) FILETIME=[0C99AE10:01C7614E] X-Spam-Score: 0.7 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KIM Yong-Woon 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 From: "Ian Chakeres" >From Date: 2007-03-03 AM 1:15:27 >On 3/2/07, Yong-Woon KIM wrote: >>>Regarding the requirements section: >>> >>> I think that R2 is a bad requirement. I would instead say that routing >>> should be efficient. Efficiency can be defined in many ways. There >>> might be 6lowpan networks where all devices are power so power usage >>> is not important. Alternatively there might be nodes that choose not >>> to participate even though they have energy. I think that requiring >>> minimal energy routing is too harsh and unrealistic. >> >> In my opinion, >> most 6lowpan devices are powered by battery and >> The battery power must be the weakest point in business. >> >> As time goes after wireless devices have been installed, >> management cost, for examples, battery cost, labor cost for >> battery change, maintenance cost, remote monitoring and management >> cost, etc. will overwhelm installation cost. >> >> Minimal energy usage is worth adopting for requirement to >> save battery cost and relevant labor cost, I think. >> >> "harsh and unrealistic" is a good expression >> but solving it must be a technical target. > >I guess my comment has more to do with how we solve the problem. I >think that a routing protocol that can handle sleeping nodes (and >adapt quickly) and also one that can be influenced by nodes >willingness (maybe remaining battery) is sufficient. Therefore, I'm >not sure we need an energy aware routing protocol. I'm not a technology expert in this area. But I'm VERY interested in how I can be winner against my competitors in my business and battle field. Energy saving is a vital factor for my business. You think R2 seems to be a bad requirement. I revisited the R2: "R02: Shortest path calculation must be based on minimal energy usage." I'm very happy with R2. Regarding your comment.. We have to define "energy aware routing protocol" first. "a routing protocol that can handle sleeping nodes (and adapt quickly) and can be influenced by nodes willingness (maybe remaining battery)" seems to me that it is a kind of energy saving routing protocol. How to save energy is a technical target to be achieved. R2 doesn't state any solution. Your idea and comment is ok to me if it is helpful for energy saving in routing operations. A new energy saving routing protocol also is ok to me. The only one that I want to ask you and sincere engineers is to give me an efficient routing protocol for energy saving. Then I can meet the TTM first. Brand-new one, adaptation or reuse is not an issue to me. I REALLY THANK YOU FOR YOUR SINCERE EFFORTS IN THIS AREA. Regards, KIM, Yong-Woon ps) I'm not a real salesman but was. I think so in my mind all the time while doing my R/D jobs. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Mar 09 13:24:23 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPjlI-00031o-Sb; Fri, 09 Mar 2007 13:24:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPjlH-00030o-4Q for 6lowpan@lists.ietf.org; Fri, 09 Mar 2007 13:24:15 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPjkv-0007Cj-TF for 6lowpan@lists.ietf.org; Fri, 09 Mar 2007 13:24:14 -0500 Received: from dnab4233bb.stanford.edu ([171.66.51.187]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1HPjkt-00077R-1Y; Fri, 09 Mar 2007 10:23:52 -0800 In-Reply-To: <374005f30703020815i66a5556dufe94995b66927599@mail.gmail.com> References: <374005f30703020815i66a5556dufe94995b66927599@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <9F438C51-450D-4CEE-89A2-81BE663B0594@cs.stanford.edu> Content-Transfer-Encoding: quoted-printable From: Philip Levis Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements Date: Fri, 9 Mar 2007 09:15:18 -0800 To: Ian Chakeres X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 1423d2bdf1536ba32d3e1b7a7c800682 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Mar 2, 2007, at 8:15 AM, Ian Chakeres wrote: > Two quick comments inline. > > On 3/2/07, =EA=B9=80=EC=9A=A9=EC=9A=B4 wrote: >> >I don't think LQI by itself should be used. LQI must be matched with >> >other indicators to make good decisions. >> >> I agree. But, in my opinion, >> LQI is likely to be the primary key. >> The reason is saving TCO. > > LQI is good for making single hop decisions, but much more complicated > when we talk about multiple hops (routing). I'd caution against just assuming that LQI will solve all single-hop =20 problems. First, LQI is not clearly defined. Radios such as the CC2420 give =20 multiple hardware indicators of link quality. The "LQI" field that =20 the CC2420 provides, for example, is not an 802.15.4 LQI value; the =20 data sheet recommends that you use other values and factors to =20 determine link quality. I have yet to hear of a good (produces stable =20= and accurate values) algorithm to compute an 802.15.4 LQI purely from =20= hardware indicators. For example, if you look at what current sensor net stacks do, they =20 essentially scale the LQI such that only very high SNR links are used =20= (think >10dBm above threshold), leading to routes that are stable but =20= are far from the shortest path. Additionally, if you have analog interference sources, then you must =20 compute LQI bidirectionally. Otherwise, you may be able to receive =20 packets from a node but it cannot receive packets from you. This is =20 also a reason why protocols such as AODV run into big problems in =20 practice, unless you constrain communication to be over a =20 bidirectional mesh that you've established underneath IP. But that's =20 the hard part and the actual protocol problem to solve: once you have =20= it, AODV and its ilk are fairly trivial. Finally, applying LQI to routing decisions is difficult, given its =20 fairly vague specification in 802.15.4. One can imagine computing =20 minimum cost paths using LQI, but it would be good to see what those =20 calculations are like in practice, and how different 802.15.4 stacks, =20= with their different LQI calculations, lead to different routing =20 performance based on the upper layers assumptions on its meaning. All together, what this means is that mesh routing is almost =20 certainly needs to have network-level information in terms of link =20 quality, which it can use to make network-level routing decisions. It =20= can use LQI as part of these decisions, but it is important to leave =20 the flexibility to incorporate other information as well. Phil= _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Mar 09 18:48:08 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPooX-00077Z-Qr; Fri, 09 Mar 2007 18:47:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPooW-00077T-Bg for 6lowpan@ietf.org; Fri, 09 Mar 2007 18:47:56 -0500 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPooV-0006sw-3t for 6lowpan@ietf.org; Fri, 09 Mar 2007 18:47:56 -0500 Received: by nf-out-0910.google.com with SMTP id l36so1343681nfa for <6lowpan@ietf.org>; Fri, 09 Mar 2007 15:47:54 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=gsvYi+RfCzJK7U+wdF2Q54CVO9DCSfBIopGxtferlg2eB7WvtxG4D6iqsmWTiKqqB+nNL35fP5az138eD+G5SPiui44PqzEpE+4spplcFqiuXmseed1uRnxoB/rVZnquNlBS/pEaxr1N5vsCXT61vsJ65nTOPpOi+T8QKstr6hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fRMeDBDJgk0wO/vUwF2zKarsi0El5X5xkS/38D9F3GCSxcYLSJnLDxvnIOhBXQUdl8jlzSAXCDt5Pef+68RTGxtoVPhmG23jWCzgmU9WRF56arI9Ra/GCRXQS6OVS9AOMZMARQ/VMdQG3a6/HUrwPmWTHF1b+bhlTM56ecq0JjQ= Received: by 10.82.135.13 with SMTP id i13mr3853462bud.1173484074272; Fri, 09 Mar 2007 15:47:54 -0800 (PST) Received: by 10.82.182.11 with HTTP; Fri, 9 Mar 2007 15:47:54 -0800 (PST) Message-ID: <43b91d370703091547t1f480eeds8a8cf8da3794a8c0@mail.gmail.com> Date: Fri, 9 Mar 2007 15:47:54 -0800 From: "Samita Chakrabarti" To: 6lowpan@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [6lowpan] Updated : draft-chakrabarti-6lowpan-ipv6-nd-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 An update version of the 6lowpan related ND draft has been posted. Comments are welcome. -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Mar 11 19:08:39 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQX9K-0002Fp-GA; Sun, 11 Mar 2007 19:08:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQX9K-0002Ff-0U for 6lowpan@ietf.org; Sun, 11 Mar 2007 19:08:22 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQX9I-00089C-NU for 6lowpan@ietf.org; Sun, 11 Mar 2007 19:08:21 -0400 Received: by nf-out-0910.google.com with SMTP id l36so1884008nfa for <6lowpan@ietf.org>; Sun, 11 Mar 2007 16:08:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=a/ub+kyc8ZWfqJGylhLJESgAaghgopr6U6JoqV+OW0mMmjJeOeQBb8SiKalFZWdXXxd1aLWTmBcTLYi9RKZGz+eYPWcBY4IQNPdHO1z04RxAcb+H5ltlRL9m8cE90XEV+rjgM0rOb729G6s6fqwP/vTAWaVIXQab0ySU2dciI+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FTL5dqdVFZ+WzTrDu0/FWJ09V2QFyWK0YFCmMb5dhv0RC9deaX2IvqBeTLaLyI0clsL2+Pk8PynK3efobVLd1qrfbyZzfazXw4OBw6AV69OmAUfiu3Cn2zeMTOxOVBswEXlDyM6ICUKOae+Zk+tNfz4MYLpm3YEg+WQMhPAxLOE= Received: by 10.82.163.13 with SMTP id l13mr7290019bue.1173654499934; Sun, 11 Mar 2007 16:08:19 -0700 (PDT) Received: by 10.82.182.11 with HTTP; Sun, 11 Mar 2007 16:08:19 -0700 (PDT) Message-ID: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> Date: Sun, 11 Mar 2007 15:08:19 -0800 From: "Samita Chakrabarti" To: 6lowpan@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [6lowpan] 6lowpan Mobility requirements draft updated 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 Hello All: We have published an updated version of 6lowpan mobility goals and requirements draft : http://www.ietf.org/internet-drafts/draft-chakrabarti-mobopts-lowpan-req-01.txt The draftname still reflects mobopts wg. We can change name to publish under 6lowpan flag next time. Please read the draft and provide comments in the mailing list. Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 12 02:32:08 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQe4V-0004cN-1K; Mon, 12 Mar 2007 02:31:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQe4T-0004Se-FB for 6lowpan@ietf.org; Mon, 12 Mar 2007 02:31:49 -0400 Received: from email2.etri.re.kr ([129.254.16.132] helo=email2.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQe4R-0003IU-RT for 6lowpan@ietf.org; Mon, 12 Mar 2007 02:31:49 -0400 Received: from etri964caf1384 ([129.254.112.135]) by email2.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 15:36:38 +0900 Message-ID: <024b01c76470$1e3b8380$8770fe81@etri964caf1384> From: "Dominik Kaspar" To: "Samita Chakrabarti" , <6lowpan@ietf.org> References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated Date: Mon, 12 Mar 2007 15:31:50 +0900 Organization: ETRI MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 12 Mar 2007 06:36:38.0126 (UTC) FILETIME=[C96458E0:01C76470] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Samita, I think there is one requirement missing, which should state that "reduced-function devices" are not to be involved in any mobility related signaling. Dominik. ----- Original Message ----- From: "Samita Chakrabarti" To: <6lowpan@ietf.org> Sent: Monday, March 12, 2007 8:08 AM Subject: [6lowpan] 6lowpan Mobility requirements draft updated > > Hello All: > > We have published an updated version of 6lowpan mobility goals and > requirements > draft : > http://www.ietf.org/internet-drafts/draft-chakrabarti-mobopts-lowpan-req-01.txt > > The draftname still reflects mobopts wg. We can change name to > publish under 6lowpan flag next time. > > Please read the draft and provide comments in the mailing list. > > 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 Mar 12 05:18:43 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQgfk-0000bs-RL; Mon, 12 Mar 2007 05:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQgfk-0000bm-4W for 6lowpan@ietf.org; Mon, 12 Mar 2007 05:18:28 -0400 Received: from an-out-0708.google.com ([209.85.132.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQgfh-0005ow-JF for 6lowpan@ietf.org; Mon, 12 Mar 2007 05:18:28 -0400 Received: by an-out-0708.google.com with SMTP id d30so1331566and for <6lowpan@ietf.org>; Mon, 12 Mar 2007 02:18:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=GxS9lCS68p9MD6T75TOiHRpT2pTqP/MYMMopB72VvibdCtrAQKJcdXx1D+J4UoXbO7w4kIAnCtfHg0A0n0GeUsJFzgJ7ldbdvH/gF5fVs5pXAs9ywFDt+JXAkYBwUxg7fCn9oeErBLCrrpVm4KT9WXWIadUTB374YHG/D4Rt6K0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=TjXG+N1IAH9C3JUhzdxUsiVV9wzRLkSfgaS+jERA+geWiLZxEUSb4pYrvAgTYOz6U9ng0h2H0UFjmGSHqSOG1283yAJNGWYk9o7UPHcLgCCXNfJBdjxEjrAA0f76Z4W8j65LBcFSIKCY1KVG8KRk79RUTAP7K3ksWohSNMgD2e4= Received: by 10.114.26.1 with SMTP id 1mr1162234waz.1173691104507; Mon, 12 Mar 2007 02:18:24 -0700 (PDT) Received: from ?129.254.112.125? ( [129.254.112.125]) by mx.google.com with ESMTP id m29sm16260811poh.2007.03.12.02.18.21; Mon, 12 Mar 2007 02:18:22 -0700 (PDT) Message-ID: <45F51ADA.1020403@gmail.com> Date: Mon, 12 Mar 2007 18:18:18 +0900 From: Myung-Ki Shin Organization: ETRI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samita Chakrabarti Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> In-Reply-To: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: myungki.shin@gmail.com 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 Samita, Good to see the requirements again. I think mobility is one of the most important drivers for 6lowpan deployment. Quick comments and questions - Most of requirements seem to be related to scenarios, not to specific mobility requirements. Do you think handover-related signaling should be involved in 6lowpan devices (e.g., "full-function devices")? if so, reduction in handover-related signaling should be also considered as one of requirements. How about "reduced-function devices" ? So, do we need two different mobility mechanisms ? > o A lowpan node in a isolated IEEE802.15.4 network that has no > connectivity outside itself, does not require to have global IPv6 > address configuration.If the routing of packets are performed at > the lowpan layer using M bit, then only link-local address > configuration is sufficient. Are routing protocols enough to support this scenario ? > o When a lowpan node moves from one personal area network(6lowpan) > to another, it should immediately inform the new PAN co-ordinator > about its presence. The PAN co-ordinator through its IPv6 router > should inform the previous IPv6 router about the new IPv6 address > of the new node that was present in the old-lowpan network. Thus > it is possible that the roaming node can still talk to its > corresponder at the old-lowpan network. Mapping from old address to new address is required ? In this case, handover-related signalling should be also involved in mobile devices ? > o A inter-6lowpan gateway protocol is needed to comunicate the new > location (IPv6 global prefixes) of the roaming 6lowpan node which > moves across different 6lowpan networks I think if mobile lowpan nodes inform home network of its new address, this inter-6lowpan gateway protocol is not required. > o As with any network, the movement of a lowpan node may introduce > security threats in the old and new LowPan Networks. Thus, > authentication of mobile lowpan node is required when it updates > the movement information to the new and old IPv6 6lowpan routers. Do you mean Binding Update - like signals with IPsec funcions ? > o A 6lowpan network may be attached to a mobile network through a > IPv6 router. For example, in a vehicle, a few 6lowpan networks > are connected through some Wifi access points to the operator's > network or Internet. The vehicle transmits data to a central > location via Internet or operator's network. In this case, there > could be 2 scenarios - 1) the 6lowpan nodes are always inside the > vehicle and they are stationary. 2) the 6lowpan nodes move and > join/detatch different 6lowpan networks within the vehicle 3) A > 6lowpan network may step out of the vehicle and find a different > wireless access point to talk to the Internet. This is one of scenarios for MANEMO. I think many folks are interested in this scenario. (this is a kind of scenario, not requirement. move it to the sec 4.) Regards, Myung-Ki, Samita Chakrabarti wrote: > Hello All: > > We have published an updated version of 6lowpan mobility goals and > requirements > draft : > http://www.ietf.org/internet-drafts/draft-chakrabarti-mobopts-lowpan-req-01.txt > > > The draftname still reflects mobopts wg. We can change name to > publish under 6lowpan flag next time. > > Please read the draft and provide comments in the mailing list. > > 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 Mar 12 10:20:30 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlNr-0004Eo-W3; Mon, 12 Mar 2007 10:20:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlNq-0004ES-1d for 6lowpan@ietf.org; Mon, 12 Mar 2007 10:20:18 -0400 Received: from relay4.ptmail.sapo.pt ([212.55.154.24] helo=sapo.pt) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQlNl-000782-Ie for 6lowpan@ietf.org; Mon, 12 Mar 2007 10:20:18 -0400 Received: (qmail 20429 invoked from network); 12 Mar 2007 14:19:57 -0000 Received: from unknown (HELO sapo.pt) (10.134.35.208) by relay4 with SMTP; 12 Mar 2007 14:19:57 -0000 Received: (qmail 14907 invoked from network); 12 Mar 2007 14:19:57 -0000 X-AntiVirus: PTMail-AV 0.3-0.90.0 X-Virus-Status: Clean (0.10898 seconds) Received: from unknown (HELO [192.168.1.10]) (tandre@sapo.pt@[85.240.135.149]) (envelope-sender ) by mta13 (qmail-ldap-1.03) with SMTP for ; 12 Mar 2007 14:19:57 -0000 Message-ID: <45F56195.1080206@dei.uc.pt> Date: Mon, 12 Mar 2007 14:20:05 +0000 From: Tiago Camilo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Samita Chakrabarti Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> In-Reply-To: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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, I also agree that the mobility will be one of the drivers of 6lowpan integration. By reading the draft I become confused by the term mobility, since there are several types of mobility. Are you referring to seamless mobility, the one that let us move one node from one network to another and still have a continuous session? Or the draft just considers nomadism, where every time a node moves it needs to establish a new session? I think you could clarify this aspect in section 2 of the draft. Another consideration that I would like to see clarified is the one regarding the concept of Home Network (HN). In normal IPv6, HN takes an important role in mobility since it’s the Home Agent that is responsible to keep track of the CoA of our MN. In the draft you named it as original IPv6 gateway (OIG). My issue is who defines the OIG? Since the lowpan nodes can be randomly placed in scenario, in my opinion there can not be a lowpan HA concept, due to the mobility and fault tolerance characterizes of such network. So it would be interesting to insert in section 4 one example, where a mobile node, not located on its primary network, needs to contact a specific lowpan node, using its Home Address (IPv6). I also agree that it’s important to refer the mobility role of reduced-function devices as suggested by previous replies. Best Regards, Tiago Camilo University of Coimbra Samita Chakrabarti wrote: > Hello All: > > We have published an updated version of 6lowpan mobility goals and > requirements > draft : > http://www.ietf.org/internet-drafts/draft-chakrabarti-mobopts-lowpan-req-01.txt > > > The draftname still reflects mobopts wg. We can change name to > publish under 6lowpan flag next time. > > Please read the draft and provide comments in the mailing list. > > 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 Thu Mar 15 02:37:29 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRjab-0003Jh-3e; Thu, 15 Mar 2007 02:37:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRjaa-0003Ii-0T for 6lowpan@lists.ietf.org; Thu, 15 Mar 2007 02:37:28 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRjaV-0000sO-L1 for 6lowpan@lists.ietf.org; Thu, 15 Mar 2007 02:37:27 -0400 Received: from [199.233.92.21] (dev21.coslabs.com [199.233.92.21]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l2F6bA9U020503 for <6lowpan@lists.ietf.org>; Thu, 15 Mar 2007 00:37:12 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain Date: Thu, 15 Mar 2007 00:39:06 -0600 Message-Id: <1173940746.9902.94.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [6lowpan] Agenda for meeting X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Folks, The Working Group meeting is first thing monday morning. The current plan for the agenda is: Introduction - 10 minutes Notewell, note takers, ... Agenda Bashing - 5 minutes Document status - 30 minutes what last minutes changes were necessary Rechartering Process - 10 minutes what is the process and what process will we use Downselecting potential topics - 1 hour Presentations - 45 minutes There were a number of comments on the two IDs during the IETF last call and the IESG review. Most did not require changes to the documents, but a couple did. These appear to be minor changes, but we will discuss them at the meeting. The main intent for this meeting is to discuss rechartering - more specifically what the WG should work on next. During the time for downselecting we will invite a discussion with folks and experts from manet and the routing area to help us understand the issues related to the various routing protocol selection paths. This topic alone could fill the entire 2.5 hours, but we manage the discussion. We ma have time for a couple short presentations - but there is no guarantee. If you would like to make a presentation please notify Carsten and myself immediately. -- if you don't have an I-D in, we need to see your slides or outline by Friday. -- if you do, we need at least some heads-up of what discussion you would like to initiate by discussing your I-D. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 15 10:07:08 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqba-0002ZF-BY; Thu, 15 Mar 2007 10:06:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqbY-0002Z7-Nu for 6lowpan@lists.ietf.org; Thu, 15 Mar 2007 10:06:56 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49] helo=moth.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRqbX-0005HK-5I for 6lowpan@lists.ietf.org; Thu, 15 Mar 2007 10:06:56 -0400 Received: from moth.iki.fi (msa@localhost [127.0.0.1]) by moth.iki.fi (8.13.8/8.13.8/Debian-3) with ESMTP id l2FE6dh2019617 for <6lowpan@lists.ietf.org>; Thu, 15 Mar 2007 16:06:39 +0200 Received: (from msa@localhost) by moth.iki.fi (8.13.8/8.13.8/Submit) id l2FE6dlZ019614; Thu, 15 Mar 2007 16:06:39 +0200 Date: Thu, 15 Mar 2007 16:06:39 +0200 Message-Id: <200703151406.l2FE6dlZ019614@moth.iki.fi> From: Markku Savela To: 6lowpan@lists.ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [6lowpan] Comment... internet-drafts/draft-ietf-6lowpan-format-11.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 Just a short question, out of curiosity I was looking for how it does the multicast mapping, and got into chapter 9 "Multicast Address Mapping". 16 bit mapping is explained, but there not a word about 64 bit mapping! Should there be some text from some IEEE standard, written in *IETF* style (I've sometimes difficulties parsing the IEEE style of protocol text :-) _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 15 10:17:16 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqlD-0008Lq-Od; Thu, 15 Mar 2007 10:16:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqlC-0008Ll-G8 for 6lowpan@ietf.org; Thu, 15 Mar 2007 10:16:54 -0400 Received: from wr-out-0506.google.com ([64.233.184.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRqlB-0006S9-AD for 6lowpan@ietf.org; Thu, 15 Mar 2007 10:16:54 -0400 Received: by wr-out-0506.google.com with SMTP id 37so200406wra for <6lowpan@ietf.org>; Thu, 15 Mar 2007 07:16:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SuIkYwGNr7Tq81NZ5kYoERejbFFZTEam/hT7IfQZM4JOoPOvqyB5IwV3c3xPuNmQkZ4PPdGnWnBQ/VvFK6aSK00O+msOjBwNNdtWdDnKw+pJqRNLjQJ+0jNozijClGP1kkqi2hvSd+FsELOs1429UdjZiILJOuY4S1gFArydB1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H153m5B74PdkXZql/s5OfIZsT9lj9B0ZA/kjaToyY8b8q/LHQRMjGhU02fA0XTocRFS5uUCr8NKj+khSCDifcM81WZHVMphU4R9wbJ+UWvCWik4ocABiSiTbIRskA8YnbBDQobPAY74GLWMhD8dRY794BZexoxq4ljgMA4nCrWY= Received: by 10.114.161.11 with SMTP id j11mr248958wae.1173968209343; Thu, 15 Mar 2007 07:16:49 -0700 (PDT) Received: by 10.115.94.12 with HTTP; Thu, 15 Mar 2007 07:16:49 -0700 (PDT) Message-ID: Date: Thu, 15 Mar 2007 23:16:49 +0900 From: "Daniel Park" To: "Dominik Kaspar" Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated In-Reply-To: <024b01c76470$1e3b8380$8770fe81@etri964caf1384> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> <024b01c76470$1e3b8380$8770fe81@etri964caf1384> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 > I think there is one requirement missing, which should state that > "reduced-function devices" are not to be involved in any mobility related > signaling. Why ? Should RFD be a stationary mode only in 6lowpan area ? Can you elaborate on your concern again ? Daniel Park _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 15 11:00:26 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrRK-0002Nn-Tj; Thu, 15 Mar 2007 11:00:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrRJ-0002LU-5b for 6lowpan@ietf.org; Thu, 15 Mar 2007 11:00:25 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRrRG-0004v9-LV for 6lowpan@ietf.org; Thu, 15 Mar 2007 11:00:25 -0400 Received: by ug-out-1314.google.com with SMTP id 72so325924ugd for <6lowpan@ietf.org>; Thu, 15 Mar 2007 08:00:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QiGuottUF8B6yHb7PvvSXzWrtcMafDZGOdx8a6mHLi/mCwlocXsEwEOD7uGykz+ba+7Z6vkRiuBGpcQ03uVuAHcVmi5wttJ/uJC8uBRO0iDkxqVd9kZRer/jhd/NW5Ipt1QGHsEoY4kZ65rFLoo/P5H840RZB8BBnHaCt6gBG58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QLIN2DykvLcCuCUpKl7At+rGqQn/UY+VOIBQPZBVuW6XZlfZVi7D0vwF7VKkA8Kk+GOY1XpV0/OE5E+mDhjJ1+cdcDGQUAQ+UBrups7JdrdrEf2zOlD8+CAPGt6F42o1kiPF72Ew00/znQ8sRPjU8K8zylhxR0QYsb+Y99YdNwA= Received: by 10.114.181.1 with SMTP id d1mr241322waf.1173970775347; Thu, 15 Mar 2007 07:59:35 -0700 (PDT) Received: by 10.115.94.12 with HTTP; Thu, 15 Mar 2007 07:59:35 -0700 (PDT) Message-ID: Date: Thu, 15 Mar 2007 23:59:35 +0900 From: "Daniel Park" To: myungki.shin@gmail.com Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated In-Reply-To: <45F51ADA.1020403@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> <45F51ADA.1020403@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 > Most of requirements seem to be related to scenarios, not to specific > mobility requirements. Given the relevant scenarios and use cases, we can end up to any specific requirements. That's my sense since 6lowpan mobility is really peculiar issue in IETF due to its link characteristics. > Do you think handover-related signaling should be involved in 6lowpan > devices (e.g., "full-function devices")? if so, reduction in > handover-related signaling should be also considered as one of > requirements. > > How about "reduced-function devices" ? > > So, do we need two different mobility mechanisms ? I guess further study should take place in here. This document is trying to list up mobility concerns in terms of 6lowpan at this stage. Solution space will be forthcoming if folks interest occurs in this group. > > o A lowpan node in a isolated IEEE802.15.4 network that has no > > connectivity outside itself, does not require to have global IPv6 > > address configuration.If the routing of packets are performed at > > the lowpan layer using M bit, then only link-local address > > configuration is sufficient. > > Are routing protocols enough to support this scenario ? What you mean by routing protocols ? > > o When a lowpan node moves from one personal area network(6lowpan) > > to another, it should immediately inform the new PAN co-ordinator > > about its presence. The PAN co-ordinator through its IPv6 router > > should inform the previous IPv6 router about the new IPv6 address > > of the new node that was present in the old-lowpan network. Thus > > it is possible that the roaming node can still talk to its > > corresponder at the old-lowpan network. > > Mapping from old address to new address is required ? > In this case, handover-related signalling should be also involved in > mobile devices ? Well, addresses (I am saying both short address and long address) needs to be binded. Otherwise, those who want to initiate its talk to mobile device can't find out its changable location. So far, I don't have any idea whether we should design a new signaling for that or resue something optimized... > > o A inter-6lowpan gateway protocol is needed to comunicate the new > > location (IPv6 global prefixes) of the roaming 6lowpan node which > > moves across different 6lowpan networks > > I think if mobile lowpan nodes inform home network of its new address, > this inter-6lowpan gateway protocol is not required. It belongs to 6lowpan architectural issue. I know this group will start working on 6lowpan architecture. Let's see what architecture will stir up... > > o As with any network, the movement of a lowpan node may introduce > > security threats in the old and new LowPan Networks. Thus, > > authentication of mobile lowpan node is required when it updates > > the movement information to the new and old IPv6 6lowpan routers. > > Do you mean Binding Update - like signals with IPsec funcions ? Well, we'd like to focus on mobility requirements as well as feasible scenarios at this stage. Once spelling out those clearly, then we will go to details especially solution spaces if allowed. But, yes we should live up to those kinds of functions in IETF in my thought. > > o A 6lowpan network may be attached to a mobile network through a > > IPv6 router. For example, in a vehicle, a few 6lowpan networks > > are connected through some Wifi access points to the operator's > > network or Internet. The vehicle transmits data to a central > > location via Internet or operator's network. In this case, there > > could be 2 scenarios - 1) the 6lowpan nodes are always inside the > > vehicle and they are stationary. 2) the 6lowpan nodes move and > > join/detatch different 6lowpan networks within the vehicle 3) A > > 6lowpan network may step out of the vehicle and find a different > > wireless access point to talk to the Internet. > > This is one of scenarios for MANEMO. > I think many folks are interested in this scenario. > (this is a kind of scenario, not requirement. move it to the sec 4.) It will take place in manemo bof in Prague. I will speak about that in there. Please join us if you are of interest. Daniel Park _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 15 11:23:24 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrnW-0002od-LA; Thu, 15 Mar 2007 11:23:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrnT-0002oY-AG for 6lowpan@ietf.org; Thu, 15 Mar 2007 11:23:19 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRrnS-0008QD-2a for 6lowpan@ietf.org; Thu, 15 Mar 2007 11:23:19 -0400 Received: by wr-out-0506.google.com with SMTP id 37so227084wra for <6lowpan@ietf.org>; Thu, 15 Mar 2007 08:23:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eCNMovbW4u4VRrjHCLVDzSxsT46T1+5n5UMgsYHWzQVF+R2O1j3iIMWm0l5Fg4+YXQkT1LNaiOgELY7LyG8gUP4zYW2OC7yHI0+k4mZSvvXYquKSprTSqXppg4tt5UBlBxXZPQ9Gayk+v73S2TEh/dCaDfcLtpTZp3BTTGod2ko= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gRVcqsMelvbjTjGb5vuReoIaY5EzFhmumit2udHiv7Cl2DivW+1FkqeT7yt/UF0R5jaw59hajK+LwK1WyPc1atlYuxDea2hfb2hgfULNMyatznfrDHI6DyKwHk8uzRYUZKoHybDAkB5rMICSQU+j7TkdgW8waDKQT7g/zY9Rkcs= Received: by 10.114.155.1 with SMTP id c1mr256896wae.1173972197191; Thu, 15 Mar 2007 08:23:17 -0700 (PDT) Received: by 10.115.94.12 with HTTP; Thu, 15 Mar 2007 08:23:17 -0700 (PDT) Message-ID: Date: Fri, 16 Mar 2007 00:23:17 +0900 From: "Daniel Park" To: "Tiago Camilo" Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated In-Reply-To: <45F56195.1080206@dei.uc.pt> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> <45F56195.1080206@dei.uc.pt> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 > By reading the draft I become confused by the term mobility, since there > are several types of mobility. Are you referring to seamless mobility, > the one that let us move one node from one network to another and still > have a continuous session? Or the draft just considers nomadism, where > every time a node moves it needs to establish a new session? > > I think you could clarify this aspect in section 2 of the draft. Mobility in this document does not have any restricted meaning. As long as we work for 6lowpan mobility, we'd like to glance at all of possibility described above. Further texts need to be added in the next version following your input of course. > Another consideration that I would like to see clarified is the one > regarding the concept of Home Network (HN). In normal IPv6, HN takes an > important role in mobility since it's the Home Agent that is responsible > to keep track of the CoA of our MN. In the draft you named it as > original IPv6 gateway (OIG). My issue is who defines the OIG? Since the > lowpan nodes can be randomly placed in scenario, in my opinion there can > not be a lowpan HA concept, due to the mobility and fault tolerance > characterizes of such network. 802.15.4 has a PAN Coordinator to manage to its child nodes. It can be used for HN. Or as pointed out at the previous reply, it depends on how to design 6lowpan architecture especially hierarchical routing architecture. > So it would be interesting to insert in section 4 one example, where a > mobile node, not located on its primary network, needs to contact a > specific lowpan node, using its Home Address (IPv6). A bit confused. Are you indicating that mobile node located in away needs to talk with any lowpan node using its Home Address ? Why not swapping its new address allocated by a new location for the old Home Address ? Am I missing anything ? > I also agree that it's important to refer the mobility role of > reduced-function devices as suggested by previous replies. Ok, Daniel Park _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 15 12:21:29 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRshE-0002HT-JB; Thu, 15 Mar 2007 12:20:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRshD-0002HL-Ln for 6lowpan@lists.ietf.org; Thu, 15 Mar 2007 12:20:55 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRsh9-0007Hw-EG for 6lowpan@lists.ietf.org; Thu, 15 Mar 2007 12:20:55 -0400 Received: from [199.233.92.21] (dev21.coslabs.com [199.233.92.21]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l2FGKo33022468 for <6lowpan@lists.ietf.org>; Thu, 15 Mar 2007 10:20:50 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain Date: Thu, 15 Mar 2007 10:22:49 -0600 Message-Id: <1173975769.9902.162.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [6lowpan] Size of datagram_tag field in Fragmentation Header 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 We received feedback during the IESG review and IETF last call about the size of the datagram_tag field. A concern was expressed over the limited size of the field. With only 10 bits and a perfect link it is possible that the value would wrap in 60 seconds, which is the IPv6 timeout. In order to deal with this, we are looking at adding another byte to the header. From my calculations below, even if we take into account support for higher speed phy's (802.15.4a / UWB) we do not need to assign all 8 bits of the added byte to the datagram_tag. At most we must add 4 bits. The question is not about WHETHER we should add the byte, it seems clear that it is necessary, unless someone in the group has information or calculations that are different. The overhead of adding the byte is only for fragmented packets and the "cost" (the two extra bytes) is amortized over at least 164 bytes. The question IS about should we allocate the entire extra byte to the datagram_tag field or should we reserve some bits for future use. Usually reserving bits is a good thing, but in this case since the header is specific to fragmentation, I'm not sure I see the utility - what might we use the extra bits for. Here are my calculations for the current 15.4 radios running at 250Kbps: First packet - 133 bytes including the PHY Second packet - 31 bytes including the PHY Clear channel assessment and Start-up - 400 bytes (in time) Total byte time to transmit 2 packets is: 400 + 133 + 400 + 31 = 964 bytes (in time) 250 Kbps => 964 * 8 * 1024 / 250000 = 31 seconds (rounded down) We really only need 1 more bit. For developing 15.4a UWB radios with a phy of 2Mbps (the assumption here is that the CCA and start-up times for 15.4a radios will be comparable to 15.4b radios): 2 Mbps => 964 * 8 * 1024 / 2000000 = 3 seconds (rounded down) We would need 4 more bits. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Mar 15 13:21:46 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRtdo-0001vZ-32; Thu, 15 Mar 2007 13:21:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRtdm-0001vO-Ky for 6lowpan@lists.ietf.org; Thu, 15 Mar 2007 13:21:26 -0400 Received: from web81902.mail.mud.yahoo.com ([68.142.207.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRtdk-00075P-64 for 6lowpan@lists.ietf.org; Thu, 15 Mar 2007 13:21:26 -0400 Received: (qmail 30673 invoked by uid 60001); 15 Mar 2007 17:21:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=XoPofvkK2NfeypOBSW7V6tjGwBH8dobBbwUv/3Y4i4XKbLXJJqKxHo4PmwwLQrW8mk+Zk532ybkenG1/mdpeGBQB4r2g9ELkv4STRilBc10mFwKd/NE28isD6aEug4vWRcswV9j55TpOOwa8VpiSLIBkulBv1ico0so1LgebLAY=; X-YMail-OSG: AraBEfUVM1mfDk5MppzlLcTM9IVhoCzxEZiOI9r3mLuNFMbdqvNUPzHvbfCpgdcX21E9BwmMzEyj8zb4qeOzzbT4j6TXL_0A7Huud5Sg22JsB4UY5F0Vk68YGVC.WwHvtzDD8onJucb3mlI- Received: from [199.72.56.200] by web81902.mail.mud.yahoo.com via HTTP; Thu, 15 Mar 2007 10:21:23 PDT X-Mailer: YahooMailRC/368.8 YahooMailWebService/0.6.132.8 Date: Thu, 15 Mar 2007 10:21:23 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Comment... internet-drafts/draft-ietf-6lowpan-format-11.txt To: Markku Savela , 6lowpan@lists.ietf.org MIME-Version: 1.0 Message-ID: <673244.28508.qm@web81902.mail.mud.yahoo.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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="===============1438883468==" Errors-To: 6lowpan-bounces@ietf.org --===============1438883468== Content-Type: multipart/alternative; boundary="0-361554645-1173979283=:28508" --0-361554645-1173979283=:28508 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Re: mcast, we don't specify 64-bit mcast cuz we only use 16-bit for that. T= his is one of the reasons we need to support both=0A=0Asimultaneously, so 1= 6-bit mcast or bcast addresses can be used regardless of what your unicast = addresses use (16 or 64-bit).=0AHaving one way of doing things (i.e., mappi= ng mcast addresses to L2 addresses) is better than having two, as per an of= ten=0Arepeated IETF principle. The current choice favors less bits on the a= ir, rather than more fine-grained mapping.=0A=0A----- Original Message ----= =0AFrom: Markku Savela =0ATo: 6lowpan@lists.ietf.org=0ASen= t: Thursday, March 15, 2007 10:06:39 AM=0ASubject: [6lowpan] Comment... int= ernet-drafts/draft-ietf-6lowpan-format-11.txt=0A=0A=0AJust a short question= , out of curiosity I was looking for how it does=0Athe multicast mapping, a= nd got into chapter 9 "Multicast Address=0AMapping".=0A=0A16 bit mapping is= explained, but there not a word about 64 bit=0Amapping! Should there be so= me text from some IEEE standard, written in=0A*IETF* style (I've sometimes = difficulties parsing the IEEE style of=0Aprotocol text :-)=0A=0A=0A________= _______________________________________=0A6lowpan mailing list=0A6lowpan@ie= tf.org=0Ahttps://www1.ietf.org/mailman/listinfo/6lowpan=0A=0A=0A=0A=0A --0-361554645-1173979283=:28508 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Re: mcast, we don't specify 64-bit mcast cuz we only u= se 16-bit for that. This is one of the reasons we need to support both
= =0Asimultaneously, so 16-bit mcast or bcast addresses can be used regardles= s of what your unicast addresses use (16 or 64-bit).
Having one way of d= oing things (i.e., mapping mcast addresses to L2 addresses) is better than = having two, as per an often
repeated IETF principle. The current choice = favors less bits on the air, rather than more fine-grained mapping.

=
----- Original Message ----
From: Markku Savela <msa@moth.iki= .fi>
To: 6lowpan@lists.ietf.org
Sent: Thursday, March 15, 2007 10:= 06:39 AM
Subject: [6lowpan] Comment... internet-drafts/draft-ietf-6lowpa= n-format-11.txt


Just a short question, out of curiosity I w= as looking for how it does
the multicast mapping, and got into chapter 9= "Multicast Address
Mapping".

16 bit mapping is explained, but th= ere not a word about 64 bit
mapping! Should there be some text from some= IEEE standard, written in
*IETF* style (I've sometimes difficulties parsing the IEEE s= tyle of
protocol text :-)


___________________________________= ____________
6lowpan mailing list
6lowpan@ietf.org
https://www1.= ietf.org/mailman/listinfo/6lowpan

--0-361554645-1173979283=:28508-- --===============1438883468== 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 --===============1438883468==-- From 6lowpan-bounces@ietf.org Thu Mar 15 13:38:10 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRttk-00054C-0D; Thu, 15 Mar 2007 13:37:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRtti-000545-Ux for 6lowpan@lists.ietf.org; Thu, 15 Mar 2007 13:37:54 -0400 Received: from web81902.mail.mud.yahoo.com ([68.142.207.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRtth-0001tC-AU for 6lowpan@lists.ietf.org; Thu, 15 Mar 2007 13:37:54 -0400 Received: (qmail 34960 invoked by uid 60001); 15 Mar 2007 17:31:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=CuBL45NUILy+e6ORtPblaZJxTmgN4sp+YFKcDrxxXDNSMJ3PWT+dGimVha6h6SrEEsUe9c/x1t/ptsWXEGDMe6RulD9euIxwGjFjG+3BUmnKX+jKB3dv8/L13K3nxaYOv4S+UjowNZcuUQCA17zUMqhiVuDx1olxbUkjLFIAiSg=; X-YMail-OSG: tfJKEY4VM1kJt6DP9TPP3gL.9EblCPb.xczZtmn6CsenC6xhGAnDm2qXnm8EExnxoBY8cdblp9l.mNeTyiF5YyKMDasCxda6jj0mf0GOx_ZC1pjqv3dfNyoxqU_BAH2W198KDrFCkaU- Received: from [199.72.56.200] by web81902.mail.mud.yahoo.com via HTTP; Thu, 15 Mar 2007 10:31:13 PDT X-Mailer: YahooMailRC/368.8 YahooMailWebService/0.6.132.8 Date: Thu, 15 Mar 2007 10:31:13 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Size of datagram_tag field in Fragmentation Header To: Geoff Mulligan , 6lowpan <6lowpan@lists.ietf.org> MIME-Version: 1.0 Message-ID: <501460.34515.qm@web81902.mail.mud.yahoo.com> X-Spam-Score: 1.4 (+) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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="===============1048707309==" Errors-To: 6lowpan-bounces@ietf.org --===============1048707309== Content-Type: multipart/alternative; boundary="0-992277165-1173979873=:34515" --0-992277165-1173979873=:34515 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I would go ahead and grow the datagram_tag by the full 8 bits in the new oc= tet as shown below. We have not needed=0Athese reserve bits so far, and wha= t we're currently addressing is the need to grow the datagram_tag space. So= I'd =0Arecommend sticking to just that and putting this fear of wraparound= to rest for good.=0A=0A-gabriel=0A=0AOLD:=0A 1 = 2=0A 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3= =0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A |1 1 0| = datagram_tag | datagram_size |=0A +-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+=0A=0A Figure 10: First Fra= gment=0A=0Ato this:=0A=0ANEW:=0A 1 = 2 3=0A 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 = 0 1 2 3 4 5 6 7 8 9 0 1=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+=0A |1 1 1| datagram_tag | = datagram_size |=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+=0A=0A Figure 10: First Fragmen= t=0AAnd similarly for=0A the subsequent fragments:=0A=0ANEW:=0A=0A = 1 2 3=0A 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A +-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A |1 1 1| = datagram_tag | datagram_size |=0A +-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A |datagram_of= fset|=0A +-+-+-+-+-+-+-+-+=0A=0A Figure 11: Subse= quent Fragments=0A=0A----- Original Message ----=0AFrom: Geoff Mulligan =0ATo: 6lowpan <6lowpan@lists.ietf.org>=0ASent: Thursday, = March 15, 2007 12:22:49 PM=0ASubject: [6lowpan] Size of datagram_tag field = in Fragmentation Header=0A=0AWe received feedback during the IESG review an= d IETF last call about the=0Asize of the datagram_tag field. A concern was= expressed over the=0Alimited size of the field. With only 10 bits and a p= erfect link it is=0Apossible that the value would wrap in 60 seconds, which= is the IPv6=0Atimeout. In order to deal with this, we are looking at addi= ng another=0Abyte to the header. From my calculations below, even if we ta= ke into=0Aaccount support for higher speed phy's (802.15.4a / UWB) we do no= t need=0Ato assign all 8 bits of the added byte to the datagram_tag. At mo= st we=0Amust add 4 bits.=0A=0AThe question is not about WHETHER we should a= dd the byte, it seems clear=0Athat it is necessary, unless someone in the g= roup has information or=0Acalculations that are different. The overhead of= adding the byte is=0Aonly for fragmented packets and the "cost" (the two e= xtra bytes) is=0Aamortized over at least 164 bytes. =0A=0AThe question IS a= bout should we allocate the entire extra byte to the=0Adatagram_tag field o= r should we reserve some bits for future use.=0AUsually reserving bits is a= good thing, but in this case since the=0Aheader is specific to fragmentati= on, I'm not sure I see the utility -=0Awhat might we use the extra bits for= .=0A=0AHere are my calculations for the current 15.4 radios running at 250K= bps:=0A=0AFirst packet - 133 bytes including the PHY=0ASecond packet - 31 b= ytes including the PHY=0AClear channel assessment and Start-up - 400 bytes = (in time)=0ATotal byte time to transmit 2 packets is:=0A 400 + 133 + 400 += 31 =3D 964 bytes (in time)=0A=0A250 Kbps =3D> 964 * 8 * 1024 / 250000 =3D = 31 seconds (rounded down)=0A=0AWe really only need 1 more bit.=0A=0AFor dev= eloping 15.4a UWB radios with a phy of 2Mbps (the assumption here=0Ais that= the CCA and start-up times for 15.4a radios will be comparable=0Ato 15.4b = radios):=0A=0A2 Mbps =3D> 964 * 8 * 1024 / 2000000 =3D 3 seconds (rounded d= own)=0A=0AWe would need 4 more bits.=0A=0A geoff=0A=0A=0A=0A=0A_________= ______________________________________=0A6lowpan mailing list=0A6lowpan@iet= f.org=0Ahttps://www1.ietf.org/mailman/listinfo/6lowpan=0A=0A=0A=0A=0A --0-992277165-1173979873=:34515 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I would go ahead and grow the datagram_tag by the full= 8 bits in the new octet as shown below. We have not needed
these reserv= e bits so far, and what we're currently addressing is the need to grow the = datagram_tag space. So I'd
recommend sticking to just that and putting = this fear of wraparound to rest for good.

-gabriel

OLD:
1 2
0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
|1 1 0| datagram_tag | datagram_size = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= Figure 10: First Fragment

to this:

N= EW:
      =20
                    1                   2                   3
       0 1=
 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 =
1|             datagram_tag          |    datagram_size    |
      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       =
                  Figure 10: First Fragment
And similarly for=0A t= he subsequent fragments:

NEW:
=0A
                           =
1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1=
 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 1|             datag=
ram_tag          |    datagram_size    |
      +-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |datagram_offset|
    =
  +-+-+-+-+-+-+-+-+

                      Figure 11: Subsequent Frag=
ments


----- Original Message ----
From: Geoff Mulli= gan <geoff@mulligan.com>
To: 6lowpan <6lowpan@lists.ietf.org>= ;
Sent: Thursday, March 15, 2007 12:22:49 PM
Subject: [6lowpan] Size = of datagram_tag field in Fragmentation Header

We received feedb= ack during the IESG review and IETF last call about the
size of the data= gram_tag field.  A concern was expressed over the
limited size of the field.  With only 10 bits and a perfe= ct link it is
possible that the value would wrap in 60 seconds, which is= the IPv6
timeout.  In order to deal with this, we are looking= at adding another
byte to the header.  From my calculations b= elow, even if we take into
account support for higher speed phy's (802.1= 5.4a / UWB) we do not need
to assign all 8 bits of the added byte to the= datagram_tag.  At most we
must add 4 bits.

The questio= n is not about WHETHER we should add the byte, it seems clear
that it is= necessary, unless someone in the group has information or
calculations = that are different.  The overhead of adding the byte is
only f= or fragmented packets and the "cost" (the two extra bytes) is
amortized = over at least 164 bytes.

The question IS about should we allocate t= he entire extra byte to the
datagram_tag field or should we reserve some= bits for future use.
Usually reserving bits is a good thing, but in this case si= nce the
header is specific to fragmentation, I'm not sure I see the util= ity -
what might we use the extra bits for.

Here are my calculati= ons for the current 15.4 radios running at 250Kbps:

First packet - 1= 33 bytes including the PHY
Second packet - 31 bytes including the PHYClear channel assessment and Start-up - 400 bytes (in time)
Total byte = time to transmit 2 packets is:
  400 + 133 + 400 + 31 =3D 964 = bytes (in time)

250 Kbps =3D> 964 * 8 * 1024 / 250000 =3D 31 seco= nds (rounded down)

We really only need 1 more bit.

For develo= ping 15.4a UWB radios with a phy of 2Mbps (the assumption here
is that t= he CCA and start-up times for 15.4a radios will be comparable
to 15.4b r= adios):

2 Mbps =3D> 964 * 8 * 1024 / 2000000 =3D 3 seconds (round= ed down)

We would need 4 more bits.

    geoff




____________= ___________________________________
6lowpan mailing list
6lowpan@ietf= .org
https://www1.ietf.org/mailman/listinfo/6lowpan

--0-992277165-1173979873=:34515-- --===============1048707309== 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 --===============1048707309==-- From 6lowpan-bounces@ietf.org Thu Mar 15 16:07:10 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwDv-0007PQ-Vr; Thu, 15 Mar 2007 16:06:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwDu-0007LV-P8 for 6lowpan@lists.ietf.org; Thu, 15 Mar 2007 16:06:54 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRwDt-00051u-4N for 6lowpan@lists.ietf.org; Thu, 15 Mar 2007 16:06:54 -0400 Received: from [199.233.92.21] (dev21.coslabs.com [199.233.92.21]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l2FK6qAA023532 for <6lowpan@lists.ietf.org>; Thu, 15 Mar 2007 14:06:52 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: multipart/mixed; boundary="=-qIRDL7EjBOUXGumYhiuW" Date: Thu, 15 Mar 2007 14:08:51 -0600 Message-Id: <1173989332.16995.7.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Subject: [6lowpan] [Fwd: Approved: draft-ietf-6lowpan-problem-08.txt (Informational RFC)] 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 --=-qIRDL7EjBOUXGumYhiuW Content-Type: text/plain Content-Transfer-Encoding: 7bit The problem statement document is moving forward! geoff --=-qIRDL7EjBOUXGumYhiuW Content-Disposition: inline Content-Description: Forwarded message - Approved: draft-ietf-6lowpan-problem-08.txt (Informational RFC) Content-Type: message/rfc822 Received: from grab.coslabs.com (mailhost [199.233.92.34]) by future.coslabs.com (8.12.8+Sun/8.12.2) with ESMTP id l2FK08pn009086 for ; Thu, 15 Mar 2007 14:00:08 -0600 (MDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l2FK005m023495 for ; Thu, 15 Mar 2007 14:00:02 -0600 (MDT) Received: by ug-out-1314.google.com with SMTP id 44so472982uga for ; Thu, 15 Mar 2007 12:59:52 -0700 (PDT) Received: by 10.78.200.3 with SMTP id x3mr576099huf.1173988792255; Thu, 15 Mar 2007 12:59:52 -0700 (PDT) X-Forwarded-To: geoffreycraigmulligan@mulligan.com X-Forwarded-For: gmulligan@gmail.com geoffreycraigmulligan@mulligan.com Delivered-To: gmulligan@gmail.com Received: by 10.78.166.5 with SMTP id o5cs129191hue; Thu, 15 Mar 2007 12:59:51 -0700 (PDT) Received: by 10.90.79.6 with SMTP id c6mr1045999agb.1173988791248; Thu, 15 Mar 2007 12:59:51 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by mx.google.com with ESMTP id 38si4445377nzk.2007.03.15.12.59.50; Thu, 15 Mar 2007 12:59:51 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning townsley@cisco.com does not designate 199.233.92.34 as permitted sender) DomainKey-Status: no key Received: from m1.dnsix.com (m1.dnsix.com [63.251.83.84]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l2FJxjGL023492 for ; Thu, 15 Mar 2007 13:59:49 -0600 (MDT) Received: from [194.146.105.14] (helo=merlot.tools.ietf.org) by m1.dnsix.com with esmtp (Exim 4.63) (envelope-from ) id 1HRx31-0000On-4D for geoff-ietf@mulligan.org; Thu, 15 Mar 2007 16:59:43 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HRw6p-0001rS-O9 for 6lowpan-chairs@tools.ietf.org; Thu, 15 Mar 2007 20:59:39 +0100 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2007 15:20:00 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2FJJxFo020642; Thu, 15 Mar 2007 15:20:00 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2FJIllq010074; Thu, 15 Mar 2007 19:19:59 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 15:19:25 -0400 Received: from [10.83.1.98] ([10.83.1.98]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 15:19:24 -0400 Message-ID: <45F99C39.6090700@cisco.com> Date: Thu, 15 Mar 2007 20:19:21 +0100 From: Mark Townsley User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: IESG Secretary CC: IESG , 6lowpan-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 15 Mar 2007 19:19:24.0629 (UTC) FILETIME=[D797C050:01C76736] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=54; t=1173986400; x=1174850400; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Approved=3A=20draft-ietf-6lowpan-problem-08.txt=20(Informatio nal=20RFC)=20 |Sender:=20 |To:=20IESG=20Secretary=20; bh=wUqZN1gFbcM4g7FxNSvQLpKQjNyH5kI6JtyZfQLj8lg=; b=TTeMZkoy7ml3XI4QsBjvawQvGBnq+w40hUYM8fnjtIMsedbzy53wh4IRqqmQFdxPLuNRpkRi mm2PFPkyW0TzJoR0KODgM4MDJ23RVgI1bIg5yhZrkK2XlnUCI+LzKfbZ; Authentication-Results: rtp-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-SA-Exim-Connect-IP: 64.102.122.149 X-SA-Exim-Rcpt-To: 6lowpan-chairs@tools.ietf.org X-SA-Exim-Mail-From: townsley@cisco.com X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on merlot.tools.ietf.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.5 tests=DNS_FROM_RFC_ABUSE, GREYLIST_ISWHITE autolearn=no version=3.1.7-deb Subject: Approved: draft-ietf-6lowpan-problem-08.txt (Informational RFC) X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Content-Transfer-Encoding: 7bit Secretary, This document is approved. - Mark --=-qIRDL7EjBOUXGumYhiuW 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 --=-qIRDL7EjBOUXGumYhiuW-- From 6lowpan-bounces@ietf.org Thu Mar 15 20:36:39 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS0Qv-0001ca-29; Thu, 15 Mar 2007 20:36:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS0Qu-0001cS-7g for 6lowpan@ietf.org; Thu, 15 Mar 2007 20:36:36 -0400 Received: from email2.etri.re.kr ([129.254.16.132] helo=email2.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS0Qs-0005nQ-LG for 6lowpan@ietf.org; Thu, 15 Mar 2007 20:36:36 -0400 Received: from etri964caf1384 ([129.254.112.135]) by email2.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 09:41:26 +0900 Message-ID: <008201c76763$250bc4e0$8770fe81@etri964caf1384> From: "Dominik Kaspar" To: "Daniel Park" References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> <024b01c76470$1e3b8380$8770fe81@etri964caf1384> Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated Date: Fri, 16 Mar 2007 09:36:32 +0900 Organization: ETRI MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 16 Mar 2007 00:41:26.0465 (UTC) FILETIME=[D44DF310:01C76763] X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Daniel, >> I think there is one requirement missing, which should state that >> "reduced-function devices" are not to be involved in any mobility related >> signaling. > > Why ? Should RFD be a stationary mode only in 6lowpan area ? Can you > elaborate on your concern again ? > Daniel Park What I meant is that reduced-function devices should be able to move without having to involve actively in any mobility protocol. Even though the separation between RFDs and FFDs is pointed out in the draft, I could not see whether different mobility-related requirements apply to them or not. For example the draft makes these two statements: - "The lowpan nodes must be able to detect its movement from one wireless LowPan to another correctly." - "When a lowpan node moves from one personal area network(6lowpan) to another, it should immediately inform the new PAN co-ordinator about its presence." In my opinion, RFD nodes should not have to detect their own movement. Their movement should *be detected* by more capable devices... what do you think? Best regards, Dominik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Mar 16 08:00:34 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSB6T-0005fg-NC; Fri, 16 Mar 2007 08:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSB6R-0005eE-KM for 6lowpan@ietf.org; Fri, 16 Mar 2007 08:00:11 -0400 Received: from relay2.ptmail.sapo.pt ([212.55.154.22] helo=sapo.pt) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HSB6O-0002kR-1h for 6lowpan@ietf.org; Fri, 16 Mar 2007 08:00:11 -0400 Received: (qmail 5568 invoked from network); 16 Mar 2007 11:59:51 -0000 Received: from unknown (HELO sapo.pt) (10.134.35.209) by relay2 with SMTP; 16 Mar 2007 11:59:51 -0000 Received: (qmail 7226 invoked from network); 16 Mar 2007 11:59:50 -0000 X-AntiVirus: PTMail-AV 0.3-0.90.1 X-Virus-Status: Clean (0.02251 seconds) Received: from unknown (HELO [192.168.1.10]) (tandre@sapo.pt@[85.240.134.95]) (envelope-sender ) by mta14 (qmail-ldap-1.03) with SMTP for ; 16 Mar 2007 11:59:50 -0000 Message-ID: <45FA86C3.9070509@dei.uc.pt> Date: Fri, 16 Mar 2007 12:00:03 +0000 From: Tiago Camilo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Daniel Park Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> <45F56195.1080206@dei.uc.pt> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Daniel, Daniel Park wrote: >> By reading the draft I become confused by the term mobility, since there >> are several types of mobility. Are you referring to seamless mobility, >> the one that let us move one node from one network to another and still >> have a continuous session? Or the draft just considers nomadism, where >> every time a node moves it needs to establish a new session? >> >> I think you could clarify this aspect in section 2 of the draft. > > Mobility in this document does not have any restricted meaning. As > long as we work for 6lowpan mobility, we'd like to glance at all of > possibility described above. Further texts need to be added in the > next version following your input of course. > >> Another consideration that I would like to see clarified is the one >> regarding the concept of Home Network (HN). In normal IPv6, HN takes an >> important role in mobility since it's the Home Agent that is responsible >> to keep track of the CoA of our MN. In the draft you named it as >> original IPv6 gateway (OIG). My issue is who defines the OIG? Since the >> lowpan nodes can be randomly placed in scenario, in my opinion there can >> not be a lowpan HA concept, due to the mobility and fault tolerance >> characterizes of such network. > > 802.15.4 has a PAN Coordinator to manage to its child nodes. It can be > used for HN. Or as pointed out at the previous reply, it depends on > how to design 6lowpan architecture especially hierarchical routing > architecture. I agree with your approach, since its the normal IPv6 behavior, my only concern is regarding the energy requirements of the PAN Coordinator in order to manage mobility of all its devices. Moreover this means that if the PAN Coordinator for some reason dies, the MN can not be reached? >> So it would be interesting to insert in section 4 one example, where a >> mobile node, not located on its primary network, needs to contact a >> specific lowpan node, using its Home Address (IPv6). > > A bit confused. Are you indicating that mobile node located in away > needs to talk with any lowpan node using its Home Address ? Why not > swapping its new address allocated by a new location for the old Home > Address ? Am I missing anything ? > I also agree, a bit confused... moreover my example can be considered in the " Mobility across two different 6lowPan networks", so you can ignore my comment. >> I also agree that it's important to refer the mobility role of >> reduced-function devices as suggested by previous replies. > > Ok, > > Daniel Park > Tiago Camilo _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Mar 16 08:10:22 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSBGI-0003l0-28; Fri, 16 Mar 2007 08:10:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSBGH-0003ku-Js for 6lowpan@ietf.org; Fri, 16 Mar 2007 08:10:21 -0400 Received: from relay3.ptmail.sapo.pt ([212.55.154.23] helo=sapo.pt) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HSBGF-0004WG-V3 for 6lowpan@ietf.org; Fri, 16 Mar 2007 08:10:21 -0400 Received: (qmail 31294 invoked from network); 16 Mar 2007 12:10:18 -0000 Received: from unknown (HELO sapo.pt) (10.134.35.208) by relay3 with SMTP; 16 Mar 2007 12:10:18 -0000 Received: (qmail 12887 invoked from network); 16 Mar 2007 12:10:15 -0000 X-AntiVirus: PTMail-AV 0.3-0.90.1 X-Virus-Status: Clean (0.02132 seconds) Received: from unknown (HELO [192.168.1.10]) (tandre@sapo.pt@[85.240.134.95]) (envelope-sender ) by mta13 (qmail-ldap-1.03) with SMTP for ; 16 Mar 2007 12:10:15 -0000 Message-ID: <45FA8936.6080801@dei.uc.pt> Date: Fri, 16 Mar 2007 12:10:30 +0000 From: Tiago Camilo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dominik Kaspar Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> <024b01c76470$1e3b8380$8770fe81@etri964caf1384> <008201c76763$250bc4e0$8770fe81@etri964caf1384> In-Reply-To: <008201c76763$250bc4e0$8770fe81@etri964caf1384> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Dominik Kaspar wrote: > Daniel, > > >>> I think there is one requirement missing, which should state that >>> "reduced-function devices" are not to be involved in any mobility >>> related >>> signaling. >> >> Why ? Should RFD be a stationary mode only in 6lowpan area ? Can you >> elaborate on your concern again ? >> Daniel Park > > What I meant is that reduced-function devices should be able to move > without having to involve actively in any mobility protocol. Even > though the separation between RFDs and FFDs is pointed out in the > draft, I could not see whether different mobility-related requirements > apply to them or not. > > For example the draft makes these two statements: > - "The lowpan nodes must be able to detect its movement from one > wireless LowPan to another correctly." > - "When a lowpan node moves from one personal area network(6lowpan) to > another, it should immediately inform the new PAN co-ordinator about > its presence." > > In my opinion, RFD nodes should not have to detect their own movement. > Their movement should *be detected* by more capable devices... what do > you think? > I agree with this approach, it is important to reduce the network activity of the RFD nodes. One possible solution of such *detect* mechanism can be incorporated as one "LowPan Neighbor Discovery Extension", in the Chakrabarti ID. Tiago Camilo University of Coimbra > Best regards, > Dominik > > > _______________________________________________ > 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 Fri Mar 16 12:53:45 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSFgK-0004ym-Q7; Fri, 16 Mar 2007 12:53:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSFgJ-0004yc-G4 for 6lowpan@lists.ietf.org; Fri, 16 Mar 2007 12:53:31 -0400 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSFgD-0007Tr-U7 for 6lowpan@lists.ietf.org; Fri, 16 Mar 2007 12:53:31 -0400 Received: from dnab42327f.stanford.edu ([171.66.50.127]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1HSFg9-0007TG-O8; Fri, 16 Mar 2007 09:53:23 -0700 In-Reply-To: <501460.34515.qm@web81902.mail.mud.yahoo.com> References: <501460.34515.qm@web81902.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <344A88AB-80C3-4A01-BF5E-49299D7DFD0E@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [6lowpan] Size of datagram_tag field in Fragmentation Header Date: Fri, 16 Mar 2007 09:53:25 -0700 To: gabriel montenegro X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: a1ccd6d2fa83ef575f7b7817ead66a1e X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Mar 15, 2007, at 10:31 AM, gabriel montenegro wrote: > I would go ahead and grow the datagram_tag by the full 8 bits in > the new octet as shown below. We have not needed > these reserve bits so far, and what we're currently addressing is > the need to grow the datagram_tag space. So I'd > recommend sticking to just that and putting this fear of wraparound > to rest for good. > I agree with Gabriel's comment. Better to pick a safe but not exorbitant bit width, so that we don't have to add undue complexity to deal with unforeseen edge cases in the future. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Mar 16 18:37:14 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSL2a-000483-Iu; Fri, 16 Mar 2007 18:36:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSL2Y-00042p-0C for 6lowpan@lists.ietf.org; Fri, 16 Mar 2007 18:36:50 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HSL2X-0004Bk-KK for 6lowpan@lists.ietf.org; Fri, 16 Mar 2007 18:36:49 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 765511769F; Fri, 16 Mar 2007 22:36:19 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HSL23-00048s-7X; Fri, 16 Mar 2007 18:36:19 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 16 Mar 2007 18:36:19 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: 6lowpan mailing list <6lowpan@lists.ietf.org>, Internet Architecture Board , 6lowpan chair <6lowpan-chairs@tools.ietf.org>, RFC Editor Subject: [6lowpan] Document Action: '6LoWPAN: Overview, Assumptions, Problem Statement and Goals' to Informational RFC 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 The IESG has approved the following document: - '6LoWPAN: Overview, Assumptions, Problem Statement and Goals ' as an Informational RFC This document is the product of the IPv6 over Low power WPAN Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-08.txt Technical Summary 6LoWPAN is specification describing how to utilize IPv6 on top of low power, low data rate, low cost personal area networks. These networks today being built using IEEE 802.15.4 standard radios. These radios have an extremely limited frame size which makes it necessary to define an adaptation layer to support link layer fragmentation and reassembly. Additionally since these networks utilize low power transmission it is necessary for the adaptation layer to support network layer mesh capabilities. This specification defines the header format for this adaptation layer. Working Group Summary The working group reached consensus on this document. Document Quality There are at least 6 independent implementations of this protocol being worked on and all concerns raised during the review and WGLC have been addressed. Geoff Mulligan is the Document Shepherd. Note to RFC Editor 1) The draft indicates in its 3rd line that the intended status is "Standards Track". However, the document should be Informational. 2) The document does not contain any normative statement (capitalized MUST, MAY, SHOULD, etc.), Section 1.1 and the reference to RFC 2119 could be safely deleted. 3) Normative references should be [ieee802.15.4] and [RFC2460], with the remaining informative. 4) OLD: An admittedly non-technical but important consideration is that intellectual property conditions for IP networking technology are either more favorable or at least better understood than proprietary and newer solutions. NEW: An admittedly non-technical but important consideration is that IP networking technology is specified in open and freely available specifications which is favorable or at least able to be better understood by a wider audience than proprietary solutions. OLD: As alluded to above, devices within LoWPANs are expected to be deployed in exceedingly large numbers. Additionally, they are expected to have limited display and input capabilities. Furthermore, the location of some of these devices may be hard to reach. Accordingly, protocols used in LoWPANs should have minimal configuration, preferably work "out of the box", be easy to bootstrap, and enable the network to self heal given the inherent unreliable characteristic of these devices. Network management should have little overhead yet be powerful enough to control dense deployment of devices. NEW: As alluded to above, devices within LoWPANs are expected to be deployed in exceedingly large numbers. Additionally, they are expected to have limited display and input capabilities. Furthermore, the location of some of these devices may be hard to reach. Accordingly, protocols used in LoWPANs should have minimal configuration, preferably work "out of the box", be easy to bootstrap, and enable the network to self heal given the inherent unreliable characteristic of these devices. The size constraints of the link layer protocol should also be considered. Network management should have little overhead yet be powerful enough to control dense deployment of devices. OLD: Network Management: One of the points of transmitting IPv6 packets, is to reuse existing protocols as much as possible. Network management functionality is critical for LoWPANs. [RFC3411] specifies SNMPv3 protocol operations. SNMP functionality may be translated "as is" to LoWPANs. However, further investigation is required to determine if it is suitable, or if an appropriate adaptation is in order. This adaptation could include limiting the data types and simplifying the Basic Encoding Rules so as to reduce the size and complexity of the ASN.1 parser, thereby reducing the memory and processing needs to better fit into the limited memory and power of LoWPAN devices. NEW: Network Management: One of the points of transmitting IPv6 packets, is to reuse existing protocols as much as possible. Network management functionality is critical for LoWPANs. However, management solutions need to meet the resource constraints as well as the minimal configuration and self healing functionality described in section 4.4. The Simple Network Management Protocol (SNMP) [RFC3410] is widely used for monitoring data sources and sensors in conventional networks. SNMP functionality may be translated "as is" to LoWPANs with the benefit to utilize existing tools. However, due to the memory, processing, and message size constraints, further investigation is required to determine if the use of SNMPv3 is suitable, or if an appropriate adaptation of SNMPv3 or use of different protocols is in order. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 19 03:08:39 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTByw-0007t9-9B; Mon, 19 Mar 2007 03:08:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTByu-0007t1-R8 for 6lowpan@ietf.org; Mon, 19 Mar 2007 03:08:36 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTByt-0005YL-5D for 6lowpan@ietf.org; Mon, 19 Mar 2007 03:08:36 -0400 Received: by nf-out-0910.google.com with SMTP id l36so984007nfa for <6lowpan@ietf.org>; Mon, 19 Mar 2007 00:08:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=omeyQizgI4uRrEFJb41I9NyeDDCYZieTKPVdq5v83ljigtBwhytgaWAvkbqL+hPytXllmY6x11N+AwDvyUF6jzaSoHfOcCRUGk1EGK/w/IoKoG2hxUMSPmwx6iYbz26R2r+lze88OQ0JnOWdHoU0SVSV2jfcXEfV0LQa/OJ6+do= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b37h0bet3GNmVPZ6mLjj324uu5tZVfJ3M6fcPZyXyPGATHZk6NSnrodIroyAkRwcowtwojZhmzeovxA1sM6v3MtbvQK/qGiQEt2zS8kTAe+C+nGN7vdWAwc5RfLLPzFhKMLIwDhBzKX0Q2T+M93uR94GBZ4maREQm3S8yapFVSM= Received: by 10.82.163.13 with SMTP id l13mr9413486bue.1174288114205; Mon, 19 Mar 2007 00:08:34 -0700 (PDT) Received: by 10.82.182.18 with HTTP; Mon, 19 Mar 2007 00:08:34 -0700 (PDT) Message-ID: <43b91d370703190008y21b94f9fv9d4abc9caff7d901@mail.gmail.com> Date: Sun, 18 Mar 2007 23:08:34 -0800 From: "Samita Chakrabarti" To: "Dominik Kaspar" Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated In-Reply-To: <024b01c76470$1e3b8380$8770fe81@etri964caf1384> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> <024b01c76470$1e3b8380$8770fe81@etri964caf1384> 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 Dominik, Why do you think that RFD's will not be involved with mobility related signalling? Do you assume that RFDs will not move ? Thanks, -Samita On 3/11/07, Dominik Kaspar wrote: > Samita, > > I think there is one requirement missing, which should state that > "reduced-function devices" are not to be involved in any mobility related > signaling. > > Dominik. > > > ----- Original Message ----- > Wrom: OYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDO > To: <6lowpan@ietf.org> > Sent: Monday, March 12, 2007 8:08 AM > Subject: [6lowpan] 6lowpan Mobility requirements draft updated > > > > > > Hello All: > > > > We have published an updated version of 6lowpan mobility goals and > > requirements > > draft : > > http://www.ietf.org/internet-drafts/draft-chakrabarti-mobopts-lowpan-req-01.txt > > > > The draftname still reflects mobopts wg. We can change name to > > publish under 6lowpan flag next time. > > > > Please read the draft and provide comments in the mailing list. > > > > 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 Mar 19 03:36:29 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTCPh-00060G-DV; Mon, 19 Mar 2007 03:36:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTCPg-0005zv-5O for 6lowpan@ietf.org; Mon, 19 Mar 2007 03:36:16 -0400 Received: from mu-out-0910.google.com ([209.85.134.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTCPd-0000np-Rw for 6lowpan@ietf.org; Mon, 19 Mar 2007 03:36:16 -0400 Received: by mu-out-0910.google.com with SMTP id g7so1652365muf for <6lowpan@ietf.org>; Mon, 19 Mar 2007 00:36:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UpYBmljJFkRE1olLYxTkTpJx1/y6F2D6Y+Q92kONNkWJl+g8sosNzA++Y2tlTnV3quoIIV1Jhc/Hzb7VaE1dCFtjy0YbUdG3HTeV9KhSpIRWIQZ2nQ2UTZTKt4ps5V091xoqkvAS1UvicUhhEyYDSSygMq/r4oQsliNCLi1o5w0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WP+4QVsdFowDsthgrrf48CUtlhiumpIOI9QSlh/7NnmcIbLVfcf3pbcOengbJl7Nvb1mkSbCPHEbA9NiDpDC6kWpmGh2gB36Q/knHsqAXEsFYAIxekgH3akfFyQDN0F3Iaw3uDM/LWzvGFSaT7cU/eZRq1qlfOCgwLW6FPupjnw= Received: by 10.82.163.13 with SMTP id l13mr9455738bue.1174289772986; Mon, 19 Mar 2007 00:36:12 -0700 (PDT) Received: by 10.82.182.18 with HTTP; Mon, 19 Mar 2007 00:36:12 -0700 (PDT) Message-ID: <43b91d370703190036o478015c9v852a5e52c5fa18b2@mail.gmail.com> Date: Sun, 18 Mar 2007 23:36:12 -0800 From: "Samita Chakrabarti" To: "Tiago Camilo" Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated In-Reply-To: <45FA8936.6080801@dei.uc.pt> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> <024b01c76470$1e3b8380$8770fe81@etri964caf1384> <008201c76763$250bc4e0$8770fe81@etri964caf1384> <45FA8936.6080801@dei.uc.pt> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Dominik and Tiago, Sorry for the delay in replying. Some additional comments are in-line. > > > > In my opinion, RFD nodes should not have to detect their own movement. > > Their movement should *be detected* by more capable devices... what do > > you think? > > > I agree with this approach, it is important to reduce the network > activity of the RFD nodes. One possible solution of such *detect* > mechanism can be incorporated as one "LowPan Neighbor Discovery > Extension", in the Chakrabarti ID. > Tiago Camilo > Can you provide an example as to how the network or FFDs will detect new nodes, that is more efficient than the RFDs doing it ? If there is a 802.15.4 level presence detection, then the FFDs can trigger some messages to the new RFD for identification and address assignment. But, it then does not know if the RFD is in sleep mode or in awake mode. Thus, FFDs will need to send periodic messages in the network - the RFDs need to respond anyway and identify themselves. So, I don't see any advantages in network initiated detection. On the other hand, if the RFD moves to a new 6lowpan network, it should associate with the new FFD at the L2 layer (association/dissociation is part of 802.15.4 spec). Once it associates with a new FFD, the FFD then can send them cached information on RA and prefix on the network ( this is not part of ND draft yet, but we can add it). But, I agree with you folks that we should specifically talk about RFD function in the requirement document. Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 19 04:22:53 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTD8P-0006WM-4l; Mon, 19 Mar 2007 04:22:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTD8O-0006W7-1V for 6lowpan@ietf.org; Mon, 19 Mar 2007 04:22:28 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTD8L-0007mD-H1 for 6lowpan@ietf.org; Mon, 19 Mar 2007 04:22:28 -0400 Received: by nf-out-0910.google.com with SMTP id l36so1001141nfa for <6lowpan@ietf.org>; Mon, 19 Mar 2007 01:22:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QJwkga+ISDxh1Gij6UAP0jmCYIV3TiKtmXuB7tZQ5IYJgGhArv/XvSOojGd3W1CtkWO3h93kVEMx0P2L/O9mBSCqLwH4ndTUBsniN7q8HBwTwQgRET6W2i4veMKl3xJgCGse9nTTMKUTQHDZV05nomMbZ/fvkmRLeoTDdUrO1Lw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YSvf3+Z7Pq3y2GFa0aTq7KxxdI2rwDQbeh6C2VdkZbdEjjUIt2bEMpUawdg33Ev7zVfIOFCK5HcHl4vhaRIs77w8711NPnsoa2REkjfPt4cWdSHgsPyepkgJD7+d/RtCVyT2QvSKQ2VpxAl4wL9y8HvY5z55KyEhNDJ75bRmON0= Received: by 10.82.114.3 with SMTP id m3mr9546478buc.1174292544322; Mon, 19 Mar 2007 01:22:24 -0700 (PDT) Received: by 10.82.182.18 with HTTP; Mon, 19 Mar 2007 01:22:24 -0700 (PDT) Message-ID: <43b91d370703190122q1ed6830anf5d295ee5b2cb6ca@mail.gmail.com> Date: Mon, 19 Mar 2007 00:22:24 -0800 From: "Samita Chakrabarti" To: myungki.shin@gmail.com Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated In-Reply-To: <45F51ADA.1020403@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> <45F51ADA.1020403@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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 Myung-Ki, > Good to see the requirements again. > I think mobility is one of the most important drivers for > 6lowpan deployment. > Thanks for your input. > Quick comments and questions - > > Most of requirements seem to be related to scenarios, not to specific > mobility requirements. > There might be one or two scenarios that are listed as part of requirements. We will check. > Do you think handover-related signaling should be involved in 6lowpan > devices (e.g., "full-function devices")? if so, reduction in > handover-related signaling should be also considered as one of > requirements. > As it was pointed out by Daniel that mobility solution will depend on the 6lowpan final architecture. Currently our architecture ( as discussed in the wg so far) is hierarchical with bunch FFDs and RFDs hanging off of FFDs and there is one IPv6 router at the top ( please see the 6lowpan-ipv6-nd draft for that assumption). But, yes, we should make it a requirement that the solution should contain minimum number of handover messages. > How about "reduced-function devices" ? > Yes, we need more text on RFDs. > So, do we need two different mobility mechanisms ? > > > o A lowpan node in a isolated IEEE802.15.4 network that has no > > connectivity outside itself, does not require to have global IPv6 > > address configuration.If the routing of packets are performed at > > the lowpan layer using M bit, then only link-local address > > configuration is sufficient. > > Are routing protocols enough to support this scenario ? Please see the 6lowpan-ipv6-nd draft. 6lowpan current architecture assumes that there is one IPv6 subnet per 6lowpan network. Thus when a RFD moves within a 6lowpan network, its mobility happens at the L2 layer - but no change in L3 layer or IPv6 address. Since packets are routed using L2-layer mesh routing, thus there should be some signaling mechansim between old and new FFDs in this case. > > > o When a lowpan node moves from one personal area network(6lowpan) > > to another, it should immediately inform the new PAN co-ordinator > > about its presence. The PAN co-ordinator through its IPv6 router > > should inform the previous IPv6 router about the new IPv6 address > > of the new node that was present in the old-lowpan network. Thus > > it is possible that the roaming node can still talk to its > > corresponder at the old-lowpan network. > > Mapping from old address to new address is required ? Yes, in this scenario, the node's movement affects the L3 layer, as it moves from one 6lowpan to another and it's global IPv6 address changes. It also depends on the application. If one periodically sends data to another node's IPv6 addr, and the destination node moves to a different 6lowpan network, then the sender node's IPv6-router needs to know where to send the data that was addressed to the destination node's old ipv6 address. > In this case, handover-related signalling should be also involved in > mobile devices ? Should be. But we are not thinking about the solution details. > > > o A inter-6lowpan gateway protocol is needed to comunicate the new > > location (IPv6 global prefixes) of the roaming 6lowpan node which > > moves across different 6lowpan networks > > I think if mobile lowpan nodes inform home network of its new address, > this inter-6lowpan gateway protocol is not required. I don't know whether we can hold the traditional home network concept here. I am not sure continuous mobility is important in 6lowpan scenarios. > > > o As with any network, the movement of a lowpan node may introduce > > security threats in the old and new LowPan Networks. Thus, > > authentication of mobile lowpan node is required when it updates > > the movement information to the new and old IPv6 6lowpan routers. > > Do you mean Binding Update - like signals with IPsec funcions ? We mean some sort of authentication. It can be some group key exchange or certificate exchange. > > > o A 6lowpan network may be attached to a mobile network through a > > IPv6 router. For example, in a vehicle, a few 6lowpan networks > > are connected through some Wifi access points to the operator's > > network or Internet. The vehicle transmits data to a central > > location via Internet or operator's network. In this case, there > > could be 2 scenarios - 1) the 6lowpan nodes are always inside the > > vehicle and they are stationary. 2) the 6lowpan nodes move and > > join/detatch different 6lowpan networks within the vehicle 3) A > > 6lowpan network may step out of the vehicle and find a different > > wireless access point to talk to the Internet. > > This is one of scenarios for MANEMO. > I think many folks are interested in this scenario. > (this is a kind of scenario, not requirement. move it to the sec 4.) > Yes. Will move to the appropriate section. -Samita > Samita Chakrabarti wrote: > > Hello All: > > > > We have published an updated version of 6lowpan mobility goals and > > requirements > > draft : > > http://www.ietf.org/internet-drafts/draft-chakrabarti-mobopts-lowpan-req-01.txt > > > > > > The draftname still reflects mobopts wg. We can change name to > > publish under 6lowpan flag next time. > > > > Please read the draft and provide comments in the mailing list. > > > > 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 Mar 19 05:53:19 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTEYJ-0006rk-1y; Mon, 19 Mar 2007 05:53:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTEYH-0006rL-Hf for 6lowpan@lists.ietf.org; Mon, 19 Mar 2007 05:53:17 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTEYD-00038D-8B for 6lowpan@lists.ietf.org; Mon, 19 Mar 2007 05:53:17 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2007 10:53:12 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2J9rCNv009120 for <6lowpan@lists.ietf.org>; Mon, 19 Mar 2007 10:53:12 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2J9rClZ013992 for <6lowpan@lists.ietf.org>; Mon, 19 Mar 2007 09:53:12 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 10:53:12 +0100 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: Mon, 19 Mar 2007 10:53:05 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC03A4D71E@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MANEMO info Thread-Index: AcdqDGP6OT2r+B0DR6yxN/Mo2b6zLQ== From: "Pascal Thubert \(pthubert\)" To: "6lowpan" <6lowpan@lists.ietf.org> X-OriginalArrivalTime: 19 Mar 2007 09:53:12.0396 (UTC) FILETIME=[683760C0:01C76A0C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=191; t=1174297992; x=1175161992; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20MANEMO=20info |Sender:=20; bh=sU1mxEOcG/EU/CxlVsil4gX7nyISp/DM3TbUfGJfInU=; b=tl8DZPkAoGCw3tqLDoGijWoMTLr+bFz1auP2RuT/nYMXgiUq54l9wumHGK8YgPkoeAyIP7vr /ncOz3sqPWhamFGDVZu/osKA3Zbf9kK8q/j7/bQPppKnAzzibdCAZ9r5; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [6lowpan] MANEMO info 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 Here's the information about the pre BOF for MANEMO: http://www.mobileip.jp/MANEMO/IETF68.html=20 The room for pre-BOF is Tyrolka. About 30 people can fit in this room. Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 19 09:10:59 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHdI-0000tT-2m; Mon, 19 Mar 2007 09:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHdH-0000rK-2A for 6lowpan@ietf.org; Mon, 19 Mar 2007 09:10:39 -0400 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTHd0-0002vs-EF for 6lowpan@ietf.org; Mon, 19 Mar 2007 09:10:39 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l2JDAGZc027725; Mon, 19 Mar 2007 14:10:16 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E1BD2A9-F11E-4B64-8D5B-369C42910A04@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Mon, 19 Mar 2007 14:10:14 +0100 To: 6lowpan@ietf.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Carsten Bormann Subject: [6lowpan] post-IETF-last-call fix: Fixing the value of P 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 Section 10.2 of the format document defines the value of P as "TBD", waiting for IANA assignment, and section 12 accordingly states: This document requests an IANA assignment of a port number P, for use with UDP header compression (Section 10.2). This port number P is used as the base to which the "short_port" 4-bit values are added in order to obtain the actual UDP port used. This has raised a DISCUSS from the IESG, and from the discussion the the 6lowpan meeting today, it is clear that this is incorrect. There is no intention to actually allocate a port for a specific protocol (and if there were, we should be allocating 16 ports in sequence, which would require some justification). Instead, the UDP header compression mechanism just causes port numbers from the range [P..P+15] to be compressed better than other UDP port nunbers. Experience with managing small number spaces (cf. Payload Types in RTP) suggests this space would not be allocated one-by-one to applications, but it should be a dynamic space. Indeed, there is no need to "reserve" the port numbers in the [P..P+15] range -- receivers are free to put their listeners there and senders are free to use these ports as the source ports. The IANA allocated port number space already has already allocated 16384 ports for dynamic use, we don't need a new allocation. The result of the meeting was that the [P..P+15] space should simply be somewhere in this space. We just need to pick a P between 49152 and 65520. A highly scientific process run in the meeting room after the close of the meeting resulted in the choice of 61616 (0xF0B0) as a good value for P. As a result, I propose the fix below as an expression of the meeting consensus. We now need to know quickly whether there is any problem with this minor change. Gruesse, Carsten Change the text in 10.2 as follows: OLD: UDP source port (bit 0): 0: Not compressed, carried "in-line" (Section 10.3.2) 1: Compressed to 4 bits. The actual 16-bit source 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 10.3.2) UDP destination port (bit 1): 0: Not compressed, carried "in-line" (Section 10.3.2) 1: Compressed to 4 bits. The actual 16-bit 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 10.3.2) NEW: UDP source port (bit 0): 0: Not compressed, carried "in-line" (Section 10.3.2) 1: Compressed to 4 bits. The actual 16-bit source port is obtained by calculating: P + short_port value. The value of P is the number 61616 (0xF0B0). The short_port is expressed as a 4-bit value which is carried "in-line" (Section 10.3.2) UDP destination port (bit 1): 0: Not compressed, carried "in-line" (Section 10.3.2) 1: Compressed to 4 bits. The actual 16-bit destination port is obtained by calculating: P + short_port value. The value of P is the number 61616 (0xF0B0). The short_port is expressed as a 4-bit value which is carried "in-line" (Section 10.3.2) In 12, strike: OLD: This document requests an IANA assignment of a port number P, for use with UDP header compression (Section 10.2). This port number P is used as the base to which the "short_port" 4-bit values are added in order to obtain the actual UDP port used. NEW: (no replacement text). _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 19 09:43:08 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTI8i-0001fD-JU; Mon, 19 Mar 2007 09:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTI8h-0001f4-Ax for 6lowpan@ietf.org; Mon, 19 Mar 2007 09:43:07 -0400 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTI8K-0000hH-Vv for 6lowpan@ietf.org; Mon, 19 Mar 2007 09:43:07 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l2JDgYLl024369; Mon, 19 Mar 2007 14:42:34 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F0ED58D-D3F2-4C80-B9D5-86CAB211FA0D@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Mon, 19 Mar 2007 14:42:32 +0100 To: 6lowpan@ietf.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Carsten Bormann Subject: [6lowpan] Agenda and slides from the 6lowpan meeting at the meeting materials site 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 https://datatracker.ietf.org/public/meeting_materials.cgi? meeting_num=68#wg-6lowpan Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 19 11:26:44 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJky-0002zZ-5K; Mon, 19 Mar 2007 11:26:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJkx-0002z5-4X for 6lowpan@ietf.org; Mon, 19 Mar 2007 11:26:43 -0400 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJkf-0003r3-8z for 6lowpan@ietf.org; Mon, 19 Mar 2007 11:26:43 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l2JFQNhP004799; Mon, 19 Mar 2007 16:26:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Mon, 19 Mar 2007 16:26:17 +0100 To: 6lowpan@ietf.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Carsten Bormann Subject: [6lowpan] post-IETF-last-call fix: Extending the Datagram-Tag 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 As was discussed previously on the mailing list, the datagram-tag size was a bit aggressively small at 10 bits, which got us another DISCUSS comment. Datagram-Tags need to be unique over the time a receiver keeps fragments for reassembly, and Geoff has calculated a sender could only use half a 256 kbit/s link with 10 bits of datagram-tag, a situation that would become worse with the faster links in the pipeline. So we need to add a byte. What do we do with the 8 new bits? Allocate them all to the datagram-tag? This provides some future- proofing, but we only really need 4 or 5 bits in the immediate future. We couldn't quite figure out what to do with any "reserved bits" so far, so the mailing list consensus so far was to use all 8 bits. This leads to a somewhat awkward tag size of 18 bits. In the meeting today, we discussed cutting back to 16, reshuffling the header to obtain alignment, and assigning the two "reserved bits" to the header type discriminator. Simpler to implement, and future- proofing in a different way (by leaving bits for extensions). The text proposal below does not attempt to fix the ambiguity of: The sender SHALL increment datagram_tag for successive, fragmented datagrams. If anyone thinks this is absolutely required, they should define whether this is a single value per sender, incremented for every new datagram, or whether a sender has to keep (indefinitely!?) per- receiver counters. Separate from this detail, if there are any issues with the text proposed below, we need to know quickly. Gruesse, Carsten OLD: 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0| datagram_tag | datagram_size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: First Fragment NEW: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 0 0| datagram_size | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: First Fragment OLD: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1| datagram_tag | datagram_size |datagram_offset| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Subsequent Fragments NEW: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 0| datagram_size | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |datagram_offset| +-+-+-+-+-+-+-+-+ Figure 11: Subsequent Fragments OLD: datagram_tag: The value of datagram_tag (datagram tag) SHALL be the same for all link fragments of a payload (e.g., IPv6) datagram. The sender SHALL increment datagram_tag for successive, fragmented datagrams. The incremented value of datagram_tag SHALL wrap from 1023 back to zero. This field is 10 bits long, and its initial value is not defined. NEW: datagram_tag: The value of datagram_tag (datagram tag) SHALL be the same for all link fragments of a payload (e.g., IPv6) datagram. The sender SHALL increment datagram_tag for successive, fragmented datagrams. The incremented value of datagram_tag SHALL wrap from 65535 back to zero. This field is 16 bits long, and its initial value is not defined. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 19 13:00:49 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLE1-0005eP-1n; Mon, 19 Mar 2007 13:00:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLDz-0005du-8V for 6lowpan@ietf.org; Mon, 19 Mar 2007 13:00:47 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTLDq-00033n-Nv for 6lowpan@ietf.org; Mon, 19 Mar 2007 13:00:47 -0400 Received: by nf-out-0910.google.com with SMTP id l36so1178798nfa for <6lowpan@ietf.org>; Mon, 19 Mar 2007 10:00:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=cXZwXJwrmjEJB+oRiZm/BzsxmWYHuiYx3CBS4V3wkQ0bYuNyAW5wUNMWo8X5rmObdttXzHKaByS0YVN3J9Mv1bk40KrR8SlHkws6SmIzGroBKwZ9MS7BzI7gR+szbFG3EaMPHUKxR0RL3kCWF54au3QN3sKlGOmfvQjwN2Ob9Eo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=odeEmLXCj9X2UoLIXhVL2e09qywutJo1p2Xv/T6v+bHhZ7mfgC/2Q7vzRxiH+X2fMVOTUbkY7wV1wHNp5Pk2NBock9JYKw2ib4uxQ87Kk6ZP1H/SUrOxIhOPDnU3mv04DzEikL4HWD64Odyt9/FdzffMS/8vDxbK3989Bw7V2yI= Received: by 10.82.148.7 with SMTP id v7mr10433906bud.1174323638176; Mon, 19 Mar 2007 10:00:38 -0700 (PDT) Received: by 10.82.134.8 with HTTP; Mon, 19 Mar 2007 10:00:38 -0700 (PDT) Message-ID: Date: Mon, 19 Mar 2007 10:00:38 -0700 From: "David Culler" To: 6lowpan@ietf.org, cabo@tzi.org Subject: [6lowpan] post-IETF-last-call fix: Extending the Datagram-Tag MIME-Version: 1.0 X-Spam-Score: 0.1 (/) 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: , Content-Type: multipart/mixed; boundary="===============0738648516==" Errors-To: 6lowpan-bounces@ietf.org --===============0738648516== Content-Type: multipart/alternative; boundary="----=_Part_122264_30565066.1174323638150" ------=_Part_122264_30565066.1174323638150 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Carsten, I think that you have captured the discussion very well and this is a big improvement. My only concern is that we don't confuse the upper two bits. They should be reserved and undefined at this stage, rather than counted on to be zero. If one is masking the upper bits to produce a valid 16 bit size, all upper 5 should be masked. NEW: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 R R| datagram_size | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: First Fragment NEW: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 R R| datagram_size | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |datagram_offset| +-+-+-+-+-+-+-+-+ Figure 11: Subsequent Fragments ------=_Part_122264_30565066.1174323638150 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Carsten,
   I think that you have captured the discussion very well and this is a big improvement.  My only concern is that we don't confuse the upper two bits.  They should be reserved and undefined at this stage, rather than counted on to be zero.  If one is masking the upper bits to produce a valid 16 bit size, all upper 5 should be masked. 



NEW:
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |1 1 0 R R|    datagram_size    |         datagram_tag          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                         Figure 10: First Fragment


NEW:
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |1 1 1 R R|    datagram_size    |         datagram_tag          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |datagram_offset|
      +-+-+-+-+-+-+-+-+

                      Figure 11: Subsequent Fragments

------=_Part_122264_30565066.1174323638150-- --===============0738648516== 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 --===============0738648516==-- From 6lowpan-bounces@ietf.org Mon Mar 19 14:23:41 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMWD-00059g-Pn; Mon, 19 Mar 2007 14:23:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMWC-00059S-AT for 6lowpan@ietf.org; Mon, 19 Mar 2007 14:23:40 -0400 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTMW8-0002WO-RP for 6lowpan@ietf.org; Mon, 19 Mar 2007 14:23:40 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l2JHrwgj019303; Mon, 19 Mar 2007 18:53:58 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E3B6125-3B74-48B8-8AC3-30B1BB97D077@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Mon, 19 Mar 2007 18:53:55 +0100 To: 6lowpan@ietf.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Carsten Bormann Subject: [6lowpan] Open DISCUSS Editorials 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 The following IESG comments appear editorial to me. They do need to be addressed, though. Any takers? Gruesse, Carsten ################################# * Prefix issue Jari Arkko: Discuss [2007-03-08]: > This document assumes that a PAN maps to a specific IPv6 link, hence > it implies a unique prefix. Knowledge of the 16-bit PAN ID (e.g., by > including it in the IEEE 802.15.4 headers) would enable automatically > mapping it to the corresponding IPv6 prefix. One possible method is > to concatenate the 16 bits of PAN ID to a /48 in order to obtain the > 64-bit link prefix. Whichever method is used, the assumption in this > document is that a given PAN ID maps to a unique IPv6 prefix. This Please explain how this relates to regular IPv6 prefix configuration methods (such as RAs) and whether this prevents the configuration of multiple prefixes on the same link. > As usual, hosts learn IPv6 prefixes via router advertisements as per > [I-D.ietf-ipv6-2461bis]. The working group may pursue additional > mechanisms as well. Please delete the second sentence. Further work is always possible, but you have to provide an unambigious definition of what IPv6 over 802.15.4 means in this document. ################################# * Multicast issue > Additionally, support for mapping of IPv6 multicast addresses MAY be > provided as per Section 9. A full specification of such > functionality is out of scope of this document. This seems to suggest that there are two ways to implement multicast over 802.15.4. Let me quote RFC 1958, architectural principles of the Internet: "3.2 If there are several ways of doing the same thing, choose one." Specifically, there is no negotiation whether multicast is implemented via broadcast or the suggested scheme, so how would node be able to determine what they should be sending? Also, the description in Section 9 seems to indicate that it is incomplete. One way to resolve this is to remove the second approach, i.e., Section 9. However, this implies that all nodes within a 802.15.4 network will need to wake up when one of them is called upon in, say, Neighbor Solicitation. ################################# * Incorrect, but inconsequential statement... > datagram_size: This 11 bit field encodes the size of the entire IP > payload datagram. The value of datagram_size SHALL be the same > for all link fragments of an IP payload datagram. For IPv6, this > SHALL be 40 octets (the size of the uncompressed IPv6 header) more > than the value of Payload Length in the IPv6 header [RFC2460]. > Typically, this field needs to encode a maximum length of 1280 > (IEEE 802.15.4 link MTU as defined in this document), and as much > as 1500 (the default maximum IPv6 packet size if IPv6 > fragmentation is in use). Therefore, this field is 11 bits long, > which works in either case. The latter part seems incorrect. If IPv6 fragmentation is in use, the recommended minimum packet size from RFC 2460 is indeed 1500 bytes. However, each individual IPv6 packet fragment carries a payload length field <= path MTU, i.e., in this case 1280 or smaller. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 19 14:23:44 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMWF-0005AT-Vn; Mon, 19 Mar 2007 14:23:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMWE-0005AK-Vg for 6lowpan@ietf.org; Mon, 19 Mar 2007 14:23:43 -0400 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTMWC-0002WO-Ie for 6lowpan@ietf.org; Mon, 19 Mar 2007 14:23:42 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l2JHtidd020291; Mon, 19 Mar 2007 18:55:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Mon, 19 Mar 2007 18:55:42 +0100 To: 6lowpan@ietf.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: Carsten Bormann Subject: [6lowpan] Proposal for DISCUSS Editorials X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org I'm proposing the following disposition of the editorial IESG comments that weren't in my previous message. Again, quick feedback is useful. Gruesse, Carsten ################################# * Editorial 1 From Gen-ART review by Joel Halpern: I don't know that I have ever seen a document before that says "thou shalt not extend this." (Section 5, last sentence before 5.1, "All headers used in LOWPAN adaptation layer SHALL be defined in this format document.") ===> INTERPRET COMMENT My view of this is that this is indeed the intention. Of course, evolving this spec itself should be possible. Note that this would require some version management, which will need to be addressed by bootstrapping. ################################# * Editorial 2 The fragmentation technique sends an offset that is in multiple of 8 bytes. It would be sensible to say that all fragments except the last SHOULD (MUST?) be multiple of eight bytes, so that the fragment offset works well. (section 5.3) ===> ACCEPT COMMENT AND CHANGE TEXT OLD: If an entire payload (e.g., IPv6) datagram fits within a single 802.15.4 frame, it is unfragmented and the LoWPAN encapsulation should contain no fragmentation header. If the datagram does not fit within a single IEEE 802.15.4 frame, it SHALL be broken into link fragments. The first link fragment SHALL contain the first fragment header (defined by one-bit as the first two bits and a zero-bit as the third bit) shown below. NEW: If an entire payload (e.g., IPv6) datagram fits within a single 802.15.4 frame, it is unfragmented and the LoWPAN encapsulation should contain no fragmentation header. If the datagram does not fit within a single IEEE 802.15.4 frame, it SHALL be broken into link fragments. As the fragment offset can only express multiples of eight bytes, all link fragments for a datagram except the last one MUST be multiples of eight bytes in length. The first link fragment SHALL contain the first fragment header (defined by one-bit as the first two bits and a zero-bit as the third bit) shown below. (This is a new MUST, but sensible implementations would have discarded non-aligned non-final fragments anyway because of the non-overlap mandate.) ################################# * Editorial 3 At the beginning of section 10.1 on Encoding IPv6 Header fields, the wording is slightly misleading. The wording says "The following common IPv6 header values may be compressed from the onset..." I would suggest instead "The following IPv6 header values are expected to be common on 6lowPan networks, so the HC1 header has been constructed to efficiently compress them from the onset." ===> ACCEPT COMMENT AND CHANGE TEXT OLD: By virtue of having joined the same 6LoWPAN network, devices share some state. This makes it possible to compress headers even in the absence of the customary context-building phase. Thus, the following common IPv6 header values may be compressed from the onset: Version ... NEW: By virtue of having joined the same 6LoWPAN network, devices share some state. This makes it possible to compress headers without explicitly building any compression context state; 6lowpan header compression therefore does not keep any flow state, but relies entirely on information pertaining to the entire link. The following IPv6 header values are expected to be common on 6lowPan networks, so the HC1 header has been constructed to efficiently compress them from the onset: Version ... ################################# * Editorial 4 Dan Romascanu: Comment [2007-03-05]: The following two Informative References do not seem to be used: [I-D.ietf-ipngwg-icmp-v3] Conta, A., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005. [I-D.ietf-ipv6-node-requirements] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node-requirements-11 (work in progress), August 2004. ===> REMOVE UNUSED REFERENCES ################################# * Editorial 5 Comment [2007-03-06]: Section 3, last paragrpah: The working group may pursue additional mechanisms as well. Is this the right document to state a possible direction of a WG? ===> REMOVE SENTENCE ################################# * HC editorial complex Magnus Westerlund: Discuss [2007-03-08]: Section 10.1: By virtue of having joined the same 6LoWPAN network, devices share some state. This makes it possible to compress headers even in the absence of the customary context-building phase. Thus, the following common IPv6 header values may be compressed from the onset: Version is IPv6; both IPv6 source and destination addresses are link local; the IPv6 interface identifiers (bottom 64 bits) for the source or destination addresses can be inferred from the layer two source and destination addresses (of course, this is only possible for interface identifiers derived from an underlying 802.15.4 MAC address); the packet length can be inferred either from layer two ("Frame Length" in the IEEE 802.15.4 PPDU) or from the "datagram_size" field in the fragment header (if present); both the Traffic Class and the Flow Label are zero; and the Next Header is UDP, ICMP or TCP. Currently this is written such as that one get the impression that these assumptions always will be true. Instead as it seems it should be interpret, in case the fields has the following values gains in HC can be made. ===> SEE EDITORIAL 3 ABOVE. COVERED. The text is also confusing the reader if there exist a context state or not. For example: Preliminary context is often required. If so, it is highly desirable to allow building it by not relying exclusively on the in-line negotiation phase. For example, if we assume there is some manual configuration phase that precedes deployment (perhaps with human involvement), then one should be able to leverage this phase to set up context such that the first packet sent will already be compressed. ===> STRIKE THIS PARAGRAPH. There is also confusion about if several flows can be handled. Primarily due to the following: Existing work assumes that there are many flows between any two devices. Here, we assume that most of the time there will be only one flow, and this allows a very simple and low context flavor of header compression. ===> STRIKE PARAGRAPH Please clarify that the compression is done totally without context and thus can handle any number of flows. ===> COVERED (EDITORIAL 3 ABOVE) Section 10. Unfortuntate that this document wasn't announced on the ROHC WG list during its WGL last call. Based on that the description seems somewhat to thin to be easily implementable. I would propose that we delay the approval, update the draft and send it for an explicit review in ROHC. ===> SORRY. ROHC WG WAS AWARE ABOUT 6LOWPAN, BUT IT SHOULD HAVE BEEN ALERTED EXPLICITLY. HARD TO FIX NOW. NO NEED TO WAIT, THOUGH. Lars Eggert: Comment [2007-03-07]: Agree with Magnus' points about the header compression specification. ===> COVERED (ABOVE). _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Mar 19 14:23:52 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMWO-0005KC-RJ; Mon, 19 Mar 2007 14:23:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMWM-0005Io-NJ for 6lowpan@ietf.org; Mon, 19 Mar 2007 14:23:50 -0400 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTMWI-0002YS-P8 for 6lowpan@ietf.org; Mon, 19 Mar 2007 14:23:50 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l2JHbjma009934; Mon, 19 Mar 2007 18:37:46 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <323FD59F-4430-4D49-B2D9-C2D129A12462@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [6lowpan] post-IETF-last-call fix: Extending the Datagram-Tag Date: Mon, 19 Mar 2007 18:37:44 +0100 To: "David Culler" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Carsten Bormann , 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 Mar 19 2007, at 18:00, David Culler wrote: > They should be reserved and undefined at this stage But this is exactly what the proposed text says -- it only defines the 11000 and 11100 prefixes, and all other bit combinations are not defined. I would not want to pre-suppose 11xNN needs to be a Fragmentation header -- it might be something completely different. (Maybe I don't understand your concern.) BTW, this also touches on the IESG comment below. Gruesse, Carsten ################################# * Editorial 1 From Gen-ART review by Joel Halpern: I don't know that I have ever seen a document before that says "thou shalt not extend this." (Section 5, last sentence before 5.1, "All headers used in LOWPAN adaptation layer SHALL be defined in this format document.") ===> INTERPRET COMMENT My view of this is that this is indeed the intention. Of course, evolving this spec itself should be possible. Note that this would require some version management, which will need to be addressed by bootstrapping. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 20 02:37:04 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTXxv-0002XT-Ru; Tue, 20 Mar 2007 02:37:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTXxt-0002XK-Lw for 6lowpan@ietf.org; Tue, 20 Mar 2007 02:37:01 -0400 Received: from web81913.mail.mud.yahoo.com ([68.142.207.50]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTXxs-0001Yu-20 for 6lowpan@ietf.org; Tue, 20 Mar 2007 02:37:01 -0400 Received: (qmail 60513 invoked by uid 60001); 20 Mar 2007 06:36:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=wzsrxZ+otMEn6h2Xbotv/pvods/XSwhMpqn4c1LOTPyGrEkYnEdbZk2/8tmvPYji4j1eeGMqUsWn/Yrj23ew7AerU1uDvpzUkKpA5BfeYk0TromBb4xGf2LxArhZtJrFmIFtEjdXyFXDHlfPeVrq33jgSCBtc7FoDP3rJiBoNAY=; X-YMail-OSG: YodQYcIVM1m7oMaK5A9VA4aa0RfUqKkpuB5zmhXDE8CGyHikPigeuz5ufp._oWnu4khgLqa2Ll5KhtfQ9sNL4u2Uj4a_1rB1ezm3UF4OrHmzLgV_twuzY43npPw3OjxmiahATjGArABXvTc- Received: from [131.107.0.103] by web81913.mail.mud.yahoo.com via HTTP; Mon, 19 Mar 2007 23:36:59 PDT X-Mailer: YahooMailRC/368.8 YahooMailWebService/0.6.132.8 Date: Mon, 19 Mar 2007 23:36:59 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Open DISCUSS Editorials To: Carsten Bormann , 6lowpan@ietf.org MIME-Version: 1.0 Message-ID: <411503.60497.qm@web81913.mail.mud.yahoo.com> X-Spam-Score: 1.4 (+) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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="===============1560963447==" Errors-To: 6lowpan-bounces@ietf.org --===============1560963447== Content-Type: multipart/alternative; boundary="0-268244631-1174372619=:60497" --0-268244631-1174372619=:60497 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable These are Jari's comments. I answered them yesterday cc-ing the IESG and 6l= owpan chairs.=0AThis was referred to in the slides I sent, a version of whi= ch you presented at the meeting.=0AI'd be interested to hear what the feedb= ack was. =0A=0AJari has not yet responded, though.=0A=0AI will forward that= message to the mailing list right after this one.=0A=0A-gabriel=0A=0A-----= Original Message ----=0AFrom: Carsten Bormann =0ATo: 6lowpan= @ietf.org=0ACc: Carsten Bormann =0ASent: Monday, March 19, 20= 07 10:53:55 AM=0ASubject: [6lowpan] Open DISCUSS Editorials=0A=0AThe follow= ing IESG comments appear editorial to me. They do need to =0Abe addressed= , though.=0AAny takers?=0A=0AGruesse, Carsten=0A=0A=0A#####################= ############=0A* Prefix issue=0A=0AJari Arkko:=0A=0ADiscuss [2007-03-08]:= =0A > This document assumes that a PAN maps to a specific IPv6 link, hence= =0A > it implies a unique prefix. Knowledge of the 16-bit PAN ID (e.g., by= =0A > including it in the IEEE 802.15.4 headers) would enable automatically= =0A > mapping it to the corresponding IPv6 prefix. One possible method is= =0A > to concatenate the 16 bits of PAN ID to a /48 in order to obtain the= =0A > 64-bit link prefix. Whichever method is used, the assumption in this= =0A > document is that a given PAN ID maps to a unique IPv6 prefix. This= =0A=0APlease explain how this relates to regular IPv6 prefix configuration= =0Amethods (such as RAs) and whether this prevents the configuration=0Aof m= ultiple prefixes on the same link.=0A=0A > As usual, hosts learn IPv6 prefi= xes via router advertisements as per=0A > [I-D.ietf-ipv6-2461bis]. The wor= king group may pursue additional=0A > mechanisms as well.=0A=0APlease delet= e the second sentence. Further work is always=0Apossible, but you have to p= rovide an unambigious definition=0Aof what IPv6 over 802.15.4 means in this= document.=0A=0A#################################=0A* Multicast issue=0A=0A= > Additionally, support for mapping of IPv6 multicast addresses MAY be=0A = > provided as per Section 9. A full specification of such=0A > functionali= ty is out of scope of this document.=0A=0AThis seems to suggest that there = are two ways to implement multicast=0Aover 802.15.4. Let me quote RFC 1958,= architectural principles of the=0AInternet: "3.2 If there are several ways= of doing the same thing,=0Achoose one." Specifically, there is no negotia= tion whether multicast=0Ais implemented via broadcast or the suggested sche= me, so how would=0Anode be able to determine what they should be sending? A= lso, the=0Adescription in Section 9 seems to indicate that it is incomplete= .=0A=0AOne way to resolve this is to remove the second approach, i.e.,=0ASe= ction 9. However, this implies that all nodes within a 802.15.4=0Anetwork w= ill need to wake up when one of them is called upon=0Ain, say, Neighbor Sol= icitation.=0A=0A#################################=0A* Incorrect, but incons= equential statement...=0A=0A > datagram_size: This 11 bit field encodes th= e size of the entire IP=0A > payload datagram. The value of datagram_siz= e SHALL be the same=0A > for all link fragments of an IP payload datagram= . For IPv6, this=0A > SHALL be 40 octets (the size of the uncompressed I= Pv6 header) more=0A > than the value of Payload Length in the IPv6 header= [RFC2460].=0A > Typically, this field needs to encode a maximum length o= f 1280=0A > (IEEE 802.15.4 link MTU as defined in this document), and as = much=0A > as 1500 (the default maximum IPv6 packet size if IPv6=0A > fr= agmentation is in use). Therefore, this field is 11 bits long,=0A > whic= h works in either case.=0A=0AThe latter part seems incorrect. If IPv6 fragm= entation is in use,=0Athe recommended minimum packet size from RFC 2460 is = indeed 1500=0Abytes. However, each individual IPv6 packet fragment carries = a=0Apayload length field <=3D path MTU, i.e., in this case 1280 or=0Asmalle= r.=0A=0A=0A_______________________________________________=0A6lowpan mailin= g list=0A6lowpan@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/6lowpan= =0A=0A=0A=0A=0A --0-268244631-1174372619=:60497 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
These are Jari's comments. I answered them yesterday c= c-ing the IESG and 6lowpan chairs.
This was referred to in the slides I = sent, a version of which you presented at the meeting.
I'd be interested= to hear what the feedback was.

Jari has not yet responded, though.=

I will forward that message to the mailing list right after this on= e.

-gabriel

----- Original Message ----
From: Cars= ten Bormann <cabo@tzi.org>
To: 6lowpan@ietf.org
Cc: Carsten Bor= mann <cabo@tzi.org>
Sent: Monday, March 19, 2007 10:53:55 AM
Su= bject: [6lowpan] Open DISCUSS Editorials

The following IESG com= ments appear editorial to me.  They do need to  
be addressed, t= hough.
Any takers?

Gruesse, Carsten


##################= ###############
* Prefix issue

Jari Arkko:

Discuss [2007-0= 3-08]:
> This document assumes that a PAN maps to a specific IPv6 li= nk, hence
> it implies a unique prefix.  Knowledge of the = 16-bit PAN ID (e.g., by
> including it in the IEEE 802.15.4 headers)= would enable automatically
> mapping it to the corresponding IPv6 p= refix.  One possible method is
> to concatenate the 16 bit= s of PAN ID to a /48 in order to obtain the
> 64-bit link prefix.&nb= sp; Whichever method is used, the assumption in this
> document= is that a given PAN ID maps to a unique IPv6 prefix.  This
Please explain how this relates to regular IPv6 prefix configuration
m= ethods (such as RAs) and whether this prevents the configuration
of mult= iple prefixes on the same link.

> As usual, hosts learn IPv6 prefixes via rou= ter advertisements as per
> [I-D.ietf-ipv6-2461bis].  The = working group may pursue additional
> mechanisms as well.

Ple= ase delete the second sentence. Further work is always
possible, but you= have to provide an unambigious definition
of what IPv6 over 802.15.4 me= ans in this document.

#################################
* Multica= st issue

> Additionally, support for mapping of IPv6 multicast a= ddresses MAY be
> provided as per Section 9.  A full speci= fication of such
> functionality is out of scope of this document.
This seems to suggest that there are two ways to implement multicast<= br>over 802.15.4. Let me quote RFC 1958, architectural principles of theInternet: "3.2 If there are several ways of doing the same thing,
choos= e one."  Specifically, there is no negotiation whether multicast<= br>is implemented via broadcast or the suggested scheme, so how would
node be= able to determine what they should be sending? Also, the
description in= Section 9 seems to indicate that it is incomplete.

One way to resol= ve this is to remove the second approach, i.e.,
Section 9. However, this= implies that all nodes within a 802.15.4
network will need to wake up w= hen one of them is called upon
in, say, Neighbor Solicitation.

##= ###############################
* Incorrect, but inconsequential stateme= nt...

> datagram_size:  This 11 bit field encodes the = size of the entire IP
>   payload datagram.  The= value of datagram_size SHALL be the same
>   for all link= fragments of an IP payload datagram.  For IPv6, this
>&nb= sp;  SHALL be 40 octets (the size of the uncompressed IPv6 header) mor= e
>   than the value of Payload Length in the IPv6 header [RFC2460].
>   Typically, this field needs to encode a ma= ximum length of 1280
>   (IEEE 802.15.4 link MTU as define= d in this document), and as much
>   as 1500 (the default = maximum IPv6 packet size if IPv6
>   fragmentation is in u= se).  Therefore, this field is 11 bits long,
>  = which works in either case.

The latter part seems incorrect. If IPv= 6 fragmentation is in use,
the recommended minimum packet size from RFC = 2460 is indeed 1500
bytes. However, each individual IPv6 packet fragment= carries a
payload length field <=3D path MTU, i.e., in this case 128= 0 or
smaller.


_______________________________________________=
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/m= ailman/listinfo/6lowpan

--0-268244631-1174372619=:60497-- --===============1560963447== 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 --===============1560963447==-- From 6lowpan-bounces@ietf.org Tue Mar 20 02:46:58 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTY7Q-0008G5-IT; Tue, 20 Mar 2007 02:46:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTY7O-0008Af-55 for 6lowpan@ietf.org; Tue, 20 Mar 2007 02:46:50 -0400 Received: from web81912.mail.mud.yahoo.com ([68.142.207.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTY7L-0002Yq-UJ for 6lowpan@ietf.org; Tue, 20 Mar 2007 02:46:50 -0400 Received: (qmail 42775 invoked by uid 60001); 20 Mar 2007 06:46:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=2Hhnnf/qnmSMlCpjYOLastHAJy0rVTvcTqJTT4NEq3YU72VXi2VvKYvAQy8mNCJpfZfYW00QGvCi35s9eZSPZCuh/sLYciwgbsmwJmz/Fybn0aAxBigVBnxgMT42VJ4rMXyEDudgNwX76yMWINkdmehuEGocHdMbfFC5j/8VZtY=; X-YMail-OSG: rTFN4j0VM1kVY_EDUg0ZZGaKxDs9lomWe79FQqsXVdp6DLEif5RWIZm7zlVhmU8I8aSnS47MHvnK616T.5kXdAZRI5uLB5AcpICWAm1t1weHqNyxUKBkAmclmo2SVzDSnXgPNkTI9eU- Received: from [131.107.0.103] by web81912.mail.mud.yahoo.com via HTTP; Mon, 19 Mar 2007 23:46:47 PDT X-Mailer: YahooMailRC/368.8 YahooMailWebService/0.6.132.8 Date: Mon, 19 Mar 2007 23:46:47 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] post-IETF-last-call fix: Extending the Datagram-Tag To: Carsten Bormann , David Culler MIME-Version: 1.0 Message-ID: <147726.41112.qm@web81912.mail.mud.yahoo.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Carsten Bormann , 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: , Content-Type: multipart/mixed; boundary="===============0829251741==" Errors-To: 6lowpan-bounces@ietf.org --===============0829251741== Content-Type: multipart/alternative; boundary="0-627499771-1174373207=:41112" --0-627499771-1174373207=:41112 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ok, I've made this change per Carsten's original suggestion. I also moved t= he description of the datagram_tag =0Afield after that of datagram_size, to= reflect their new order in the header.=0A=0A-gabriel=0A=0A----- Original M= essage ----=0AFrom: Carsten Bormann =0ATo: David Culler =0ACc: Carsten Bormann ; 6lowpan@ietf.org= =0ASent: Monday, March 19, 2007 10:37:44 AM=0ASubject: Re: [6lowpan] post-I= ETF-last-call fix: Extending the Datagram-Tag=0A=0AOn Mar 19 2007, at 18:00= , David Culler wrote:=0A=0A> They should be reserved and undefined at this = stage=0A=0ABut this is exactly what the proposed text says -- it only defin= es =0Athe 11000 and 11100 prefixes, and all other bit combinations are not= =0Adefined.=0A=0AI would not want to pre-suppose 11xNN needs to be a Frag= mentation =0Aheader -- it might be something completely different.=0A=0A(M= aybe I don't understand your concern.)=0A=0ABTW, this also touches on the I= ESG comment below.=0A=0AGruesse, Carsten=0A=0A#############################= ####=0A* Editorial 1=0A=0A From Gen-ART review by Joel Halpern:=0A=0A = I don't know that I have ever seen a document before that =0Asays "thou= =0Ashalt not extend this." (Section 5, last sentence before 5.1, "All =0A= headers used=0Ain LOWPAN adaptation layer SHALL be defined in this format d= ocument.")=0A=0A=3D=3D=3D> INTERPRET COMMENT=0AMy view of this is that this= is indeed the intention. Of course,=0Aevolving this spec itself should be = possible. Note that this would=0Arequire some version management, which wi= ll need to be addressed by=0Abootstrapping.=0A=0A__________________________= _____________________=0A6lowpan mailing list=0A6lowpan@ietf.org=0Ahttps://w= ww1.ietf.org/mailman/listinfo/6lowpan=0A=0A=0A=0A=0A --0-627499771-1174373207=:41112 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Ok, I've made this change per Carsten's original sugge= stion. I also moved the description of the datagram_tag
field after tha= t of datagram_size, to reflect their new order in the header.

-gabri= el

----- Original Message ----
From: Carsten Bormann <= cabo@tzi.org>
To: David Culler <david.culler@gmail.com>
Cc: = Carsten Bormann <cabo@tzi.org>; 6lowpan@ietf.org
Sent: Monday, Mar= ch 19, 2007 10:37:44 AM
Subject: Re: [6lowpan] post-IETF-last-call fix: = Extending the Datagram-Tag

On Mar 19 2007, at 18:00, David Cull= er wrote:

> They should be reserved and undefined at this stage
But this is exactly what the proposed text says -- it only defines  
the = 11000 and 11100 prefixes, and all other bit combinations are not  = ;
defined.

I would not want to pre-suppose 11xNN needs to be a Fr= agmentation  
header -- it might be something completely diffe= rent.

(Maybe I don't understand your concern.)

BTW, this also= touches on the IESG comment below.

Gruesse, Carsten

########= #########################
* Editorial 1

From Gen-ART review by J= oel Halpern:

         I don'= t know that I have ever seen a document before that  
says "th= ou
shalt not extend this."  (Section 5, last sentence before 5= .1, "All  
headers used
in LOWPAN adaptation layer SHALL be= defined in this format document.")

=3D=3D=3D> INTERPRET COMMENT<= br>My view of this is that this is indeed the intention. Of course,
evol= ving this spec itself should be possible.  Note that this would
require some= version management, which will need to be addressed by
bootstrapping.
_______________________________________________
6lowpan mailing li= st
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan<= /a>

--0-627499771-1174373207=:41112-- --===============0829251741== 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 --===============0829251741==-- From 6lowpan-bounces@ietf.org Tue Mar 20 02:47:02 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTY7O-0008A3-0Z; Tue, 20 Mar 2007 02:46:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTY7M-00089r-P1 for 6lowpan@ietf.org; Tue, 20 Mar 2007 02:46:48 -0400 Received: from web81911.mail.mud.yahoo.com ([68.142.207.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTY06-0001jj-Gq for 6lowpan@ietf.org; Tue, 20 Mar 2007 02:46:48 -0400 Received: (qmail 61850 invoked by uid 60001); 20 Mar 2007 06:39:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=sic/Z+ugbeE2PpoYzC2yWE0h3HwnH8sKA90j0S0D68OWJw5PXguIfyRDCDUWRbyPlCRB1uLOrNm4S1U1WfC6NIPf8MnxPEshdCaRNlywPsaB3iusGoN2wI9MU/9DLM7SkgMhmAZ2NmApsUYSB4W5JJPCEBiuOz6mzRRGrpMBBVg=; X-YMail-OSG: zrX5DFEVM1lubzIbl7OISSBOLeZW9v1fYrEsGfE6_kvDE5O3BLo5op05d_LOG5VrYvgHU9r8vjC8ZosUx17Efg70vpw4WtIFR59IHqOI4wL9qxj2Ksq5h1NOEK1qjXkWgLkfasf5otUywoXWy1Re8ScsGQ-- Received: from [131.107.0.103] by web81911.mail.mud.yahoo.com via HTTP; Mon, 19 Mar 2007 23:39:10 PDT X-Mailer: YahooMailRC/368.8 YahooMailWebService/0.6.132.8 Date: Mon, 19 Mar 2007 23:39:10 -0700 (PDT) From: gabriel montenegro To: 6lowpan@ietf.org MIME-Version: 1.0 Message-ID: <36115.59921.qm@web81911.mail.mud.yahoo.com> X-Spam-Score: 1.2 (+) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Subject: [6lowpan] Fw: Your IETF LC comments on draft-ietf-6lowpan-format-11.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: , Content-Type: multipart/mixed; boundary="===============0711655874==" Errors-To: 6lowpan-bounces@ietf.org --===============0711655874== Content-Type: multipart/alternative; boundary="0-422565612-1174372750=:59921" --0-422565612-1174372750=:59921 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This was my message to try to address Jari's comments during IESG review. = =0A=0AJari's has not said if this answers his concerns.=0A=0Acomments?=0A= =0A-gabriel=0A=0A----- Forwarded Message ----=0AFrom: "g_e_montenegro@yahoo= .com" =0ATo: iesg@ietf.org; geoff@mulligan.org; C= arsten Bormann ; Schumacher Christian Peter Pii ; jari.arkko@ericsson.com=0ASent: Sunday, March 18, 2007 1:18:51= PM=0ASubject: Your IETF LC comments on draft-ietf-6lowpan-format-11.txt=0A= =0AThanks Jari for your comments.=0A=0AChanges discussed below are in a ver= sion 12 under preparation but not yet =0Asubmitted. =0A=0A> Discuss [2007-0= 3-08]:=0A> > This document assumes that a PAN maps to a specific IPv6 link,= hence=0A> > it implies a unique prefix. Knowledge of the 16-bit PAN ID (e= .g., by=0A> > including it in the IEEE 802.15.4 headers) would enable autom= atically=0A> > mapping it to the corresponding IPv6 prefix. One possible m= ethod is=0A> > to concatenate the 16 bits of PAN ID to a /48 in order to ob= tain the=0A> > 64-bit link prefix. Whichever method is used, the assumptio= n in this=0A> > document is that a given PAN ID maps to a unique IPv6 prefi= x. This=0A> =0A> Please explain how this relates to regular IPv6 prefix=0A= configuration=0A> methods (such as RAs) and whether this prevents the conf= iguration=0A> of multiple prefixes on the same link.=0A=0AThe document was = written with this model in mind. Perhaps it can be made more=0Aexplicit.=0A= =0AFor example, section 3 at the end talks about prefixes in plural:=0A=0A = As usual, hosts learn IPv6 prefixes via router advertisements as per=0A = [I-D.ietf-ipv6-2461bis]. =0A=0A=0AAs currently worded, perhaps there is a= n issue in that a given PAN ID seems=0Alimited to only one prefix. A better= wording is to have a given PAN ID map=0Ato one link. =0A=0ANotice that the= header compression scheme was done such that multiple prefixes=0Aper link = work fine: no particular prefix (other than link-local) is ever assumed.=0A= Prefixes are sent in-line. And given that prefixes are learned via RAs (as = usual),=0Athere is no need for any additional text beyond that.=0A=0AThe su= ggested changes are:=0A=0AOLD:=0A=09This document assumes=0A that a PAN map= s to a specific IPv6 link, hence it=0A=09implies a unique prefix. Knowledge= of the 16-bit PAN ID (e.g., by including=0A=09it in the =0A=09IEEE 802.15.= 4 headers) would enable automatically=0A=09mapping it to the corresponding = IPv6 prefix. One possible method is to =0A=09concatenate the 16 bits of PAN= ID to a /48 in order to obtain the 64-bit=0A=09link prefix. Whichever meth= od is used, the assumption in this document=0A=09is that a given PAN ID map= s to a unique IPv6 prefix.=0A=0ANEW:=0A=09This document assumes that a PAN = maps to a specific IPv6 link. =0A=0A> =0A> > As usual, hosts learn IPv6 pre= fixes via router advertisements as per=0A> > [I-D.ietf-ipv6-2461bis]. The = working group may pursue additional=0A> > mechanisms as well.=0A> =0A> Plea= se delete the second sentence. Further work is always=0A> possible, but you= have to provide an unambigious definition=0A> of what IPv6 over 802.15.4 m= eans in this=0A document.=0A=0ADone.=0A=0A> > Additionally, support for map= ping of IPv6 multicast addresses MAY be=0A> > provided as per Section 9. A= full specification of such=0A> > functionality is out of scope of this doc= ument.=0A> =0A> This seems to suggest that there are two ways to implement = multicast=0A> over 802.15.4. Let me quote RFC 1958, architectural principle= s of the=0A> Internet: "3.2 If there are several ways of doing the same thi= ng,=0A> choose one." Specifically, there is no negotiation whether multica= st=0A> is implemented via broadcast or the suggested scheme, so how would= =0A> node be able to determine what they should be sending? Also, the=0A> d= escription in Section 9 seems to indicate that it is incomplete.=0A> =0A> O= ne way to resolve this is to remove the second approach, i.e.,=0A> Section = 9. However, this implies that all nodes within a 802.15.4=0A> network will = need to wake up when one of them=0A is called upon=0A> in, say, Neighbor So= licitation.=0A=0AWell, in the absence of any mesh,=0Agiven that there is no= actual link-layer multicast, even if the=0Amapping in Section 9 is done, t= he actual packets will travel over=0Abroadcast, so there is no difference.= =0A=0AThe only difference occurs in the mesh case. In this case, the actual= =0Amechanism is fully defined by the mesh specification (separate document)= .=0AThis document only defines that which must be common across all mesh=0A= specifications (as there probably will be more than one): the address=0Amap= ping.=0A=0ASuggested fix: this document should say that section 9 is only u= sed if mesh=0Ais in use. =0A=0ANEW:=0A=09support for mapping of IPv6 multic= ast addresses MAY be provided=0A=0AOLD:=0A=09support for mapping of IPv6 mu= lticast addresses MAY be provided=0A=09in a mesh =0A=0A=0AAnd add this line= to the beginning of "Multicast Address Mapping":=0A=0A=09The functionality= in this section MAY be=0A applied only in a mesh-enabled LoWPAN.=0A=0A> = =0A> > datagram_size: This 11 bit field encodes the size of the entire IP= =0A> > payload datagram. The value of datagram_size SHALL be the same=0A= > > for all link fragments of an IP payload datagram. For IPv6, this=0A>= > SHALL be 40 octets (the size of the uncompressed IPv6 header) more=0A>= > than the value of Payload Length in the IPv6 header [RFC2460].=0A> > = Typically, this field needs to encode a maximum length of 1280=0A> > (IE= EE 802.15.4 link MTU as defined in this document), and as much=0A> > as 1= 500 (the default maximum IPv6 packet size if IPv6=0A> > fragmentation is = in use). Therefore, this field is 11 bits long,=0A> > which works in eit= her case.=0A> =0A> The latter part seems incorrect. If IPv6 fragmentation i= s in use,=0A> the recommended minimum packet size from RFC 2460 is indeed 1= 500=0A> bytes. However,=0A each individual IPv6 packet fragment carries a= =0A> payload length field <=3D path MTU, i.e., in this case 1280 or=0A> sma= ller.=0A=0AWhat is incorrect? This is the text in 2460 I looked at when wri= ting the=0Aabove:=0A=0A A node must be able to accept a fragmented packet= that, after=0A reassembly, is as large as 1500 octets. A node is permit= ted to=0A accept fragmented packets that reassemble to more than 1500 oct= ets.=0A An upper-layer protocol or application that depends on IPv6=0A = fragmentation to send packets larger than the MTU of a path should=0A not= send packets larger than 1500 octets unless it has assurance that=0A the= destination is capable of reassembling packets of that larger=0A size.= =0A=0AOur MTU is 1280. We must accept packets as large as 1500, but no more= than that.=0AReassembly of packets larger than that is optional in 2460, a= nd we don't=0Ado that, so we only need 11 bits. Or should we make it explic= it that we don't=0A support=0APMTU discovery?=0A=0A-gabriel=0A=0A=0A=0A=0A= =0A=0A --0-422565612-1174372750=:59921 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
This was my message to try to address Jari's comments = during IESG review.

Jari's has not said if this answers his concern= s.

comments?

-gabriel

----- Forwarded Message = ----
From: "g_e_montenegro@yahoo.com" <g_e_montenegro@yahoo.com>To: iesg@ietf.org; geoff@mulligan.org; Carsten Bormann <cabo@tzi.org&g= t;; Schumacher Christian Peter Pii <schumacher@danfoss.com>; jari.ark= ko@ericsson.com
Sent: Sunday, March 18, 2007 1:18:51 PM
Subject: Your= IETF LC comments on draft-ietf-6lowpan-format-11.txt

<= pre>Thanks Jari for your comments.

Changes discussed below are in a version 12 under pr= eparation but not yet
submitted.

> Discuss [2007-03-08]:
= > > This document assumes that a PAN maps to a specific IPv6 link, he= nce
> > it implies a unique prefix. Knowledge of the 16-bit PAN I= D (e.g., by
> > including it in the IEEE 802.15.4 headers) would e= nable automatically
> > mapping it to the corresponding IPv6 prefi= x. One possible method is
> > to concatenate the 16 bits of PAN I= D to a /48 in order to obtain the
> > 64-bit link prefix. Whichev= er method is used, the assumption in this
> > document is that a g= iven PAN ID maps to a unique IPv6 prefix. This
>
> Please exp= lain how this relates to regular IPv6 prefix
configuration
> meth= ods (such as RAs) and whether this prevents the configuration
> of mu= ltiple prefixes on the same link.

The document was written with this= model in mind. Perhaps it can be made more
explicit.

For example, section= 3 at the end talks about prefixes in plural:

As usual, hosts lea= rn IPv6 prefixes via router advertisements as per
[I-D.ietf-ipv6-2461= bis].


As currently worded, perhaps there is an issue in that a= given PAN ID seems
limited to only one prefix. A better wording is to h= ave a given PAN ID map
to one link.

Notice that the header compr= ession scheme was done such that multiple prefixes
per link work fine: n= o particular prefix (other than link-local) is ever assumed.
Prefixes ar= e sent in-line. And given that prefixes are learned via RAs (as usual),
= there is no need for any additional text beyond that.

The suggested = changes are:

OLD:
=09This document assumes
that a PAN maps to= a specific IPv6 link, hence it
=09implies a unique prefix. Knowledge of= the 16-bit PAN ID (e.g., by including
=09it in the
=09IEEE 802.15.4= headers) would enable automatically
=09mapping it to the corresponding IPv6 prefix. On= e possible method is to
=09concatenate the 16 bits of PAN ID to a /48 i= n order to obtain the 64-bit
=09link prefix. Whichever method is used, t= he assumption in this document
=09is that a given PAN ID maps to a uniqu= e IPv6 prefix.

NEW:
=09This document assumes that a PAN maps to a= specific IPv6 link.

>
> > As usual, hosts learn IPv6 = prefixes via router advertisements as per
> > [I-D.ietf-ipv6-2461b= is]. The working group may pursue additional
> > mechanisms as we= ll.
>
> Please delete the second sentence. Further work is alw= ays
> possible, but you have to provide an unambigious definition
= > of what IPv6 over 802.15.4 means in this
document.

Done.
> > Additionally, support for mapping of IPv6 multicast addresse= s MAY be
> > provided as per Section 9. A full specification of s= uch
> > functionality is out of scope of this document.
>
> This seem= s to suggest that there are two ways to implement multicast
> over 80= 2.15.4. Let me quote RFC 1958, architectural principles of the
> Inte= rnet: "3.2 If there are several ways of doing the same thing,
> choos= e one." Specifically, there is no negotiation whether multicast
> is= implemented via broadcast or the suggested scheme, so how would
> no= de be able to determine what they should be sending? Also, the
> desc= ription in Section 9 seems to indicate that it is incomplete.
>
&= gt; One way to resolve this is to remove the second approach, i.e.,
>= Section 9. However, this implies that all nodes within a 802.15.4
> = network will need to wake up when one of them
is called upon
> in= , say, Neighbor Solicitation.

Well, in the absence of any mesh,
g= iven that there is no actual link-layer multicast, even if the
mapping i= n Section 9 is done, the actual packets will travel over
broadcast, so there is no = difference.

The only difference occurs in the mesh case. In this cas= e, the actual
mechanism is fully defined by the mesh specification (sepa= rate document).
This document only defines that which must be common acr= oss all mesh
specifications (as there probably will be more than one): t= he address
mapping.

Suggested fix: this document should say that = section 9 is only used if mesh
is in use.

NEW:
=09support for= mapping of IPv6 multicast addresses MAY be provided

OLD:
=09supp= ort for mapping of IPv6 multicast addresses MAY be provided
=09in a mesh=


And add this line to the beginning of "Multicast Address Mappi= ng":

=09The functionality in this section MAY be
applied only in= a mesh-enabled LoWPAN.

>
> > datagram_size: This 11 b= it field encodes the size of the entire IP
> > payload datagram.= The value of datagram_size SHALL be the same
> > for all link fragments of a= n IP payload datagram. For IPv6, this
> > SHALL be 40 octets (t= he size of the uncompressed IPv6 header) more
> > than the value= of Payload Length in the IPv6 header [RFC2460].
> > Typically, = this field needs to encode a maximum length of 1280
> > (IEEE 80= 2.15.4 link MTU as defined in this document), and as much
> > as= 1500 (the default maximum IPv6 packet size if IPv6
> > fragment= ation is in use). Therefore, this field is 11 bits long,
> > wh= ich works in either case.
>
> The latter part seems incorrect.= If IPv6 fragmentation is in use,
> the recommended minimum packet si= ze from RFC 2460 is indeed 1500
> bytes. However,
each individual= IPv6 packet fragment carries a
> payload length field <=3D path M= TU, i.e., in this case 1280 or
> smaller.

What is incorrect? T= his is the text in 2460 I looked at when writing the
above:

A node must be ab= le to accept a fragmented packet that, after
reassembly, is as large = as 1500 octets. A node is permitted to
accept fragmented packets tha= t reassemble to more than 1500 octets.
An upper-layer protocol or app= lication that depends on IPv6
fragmentation to send packets larger th= an the MTU of a path should
not send packets larger than 1500 octets = unless it has assurance that
the destination is capable of reassembli= ng packets of that larger
size.

Our MTU is 1280. We must accep= t packets as large as 1500, but no more than that.
Reassembly of packets= larger than that is optional in 2460, and we don't
do that, so we only = need 11 bits. Or should we make it explicit that we don't
support
PM= TU discovery?

-gabriel


--0-422565612-1174372750=:59921-- --===============0711655874== 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 --===============0711655874==-- From 6lowpan-bounces@ietf.org Tue Mar 20 03:15:11 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYYa-00015z-N8; Tue, 20 Mar 2007 03:14:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYYY-00015r-Or for 6lowpan@ietf.org; Tue, 20 Mar 2007 03:14:54 -0400 Received: from web81915.mail.mud.yahoo.com ([68.142.207.63]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTYYV-0005XE-Ng for 6lowpan@ietf.org; Tue, 20 Mar 2007 03:14:54 -0400 Received: (qmail 20219 invoked by uid 60001); 20 Mar 2007 07:14:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=y4vcgO2zz+RQ9t+z19FrScBZEUpJ5KCwV/IFMr9c7FpU5KAdJwwW6Q/oT9MZnGvxcCPzMv/lc4ikweqLaK0Rr+gMQDqBHdjKpO2Etj/MqzpQjvYbfKijzlCAvSaBEVOV30Vx1YpYhcaCJUWyf/xO7YbmSUyNAqmeB0bSU2Vu+m0=; X-YMail-OSG: 4wGGowMVM1nVCx_7jBEn0dYLqMSOpYfuRRKxsAVJiyOrBX4ebaTftEWm9CGkWqBWRg-- Received: from [131.107.0.103] by web81915.mail.mud.yahoo.com via HTTP; Tue, 20 Mar 2007 00:14:51 PDT X-Mailer: YahooMailRC/368.8 YahooMailWebService/0.6.132.8 Date: Tue, 20 Mar 2007 00:14:51 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Proposal for DISCUSS Editorials To: Carsten Bormann , 6lowpan@ietf.org MIME-Version: 1.0 Message-ID: <246097.19586.qm@web81915.mail.mud.yahoo.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc Cc: Carsten Bormann 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="===============1979125703==" Errors-To: 6lowpan-bounces@ietf.org --===============1979125703== Content-Type: multipart/alternative; boundary="0-594892295-1174374891=:19586" --0-594892295-1174374891=:19586 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable inline marked "gab>"=0A=0A----- Original Message ----=0AFrom: Carsten Borma= nn =0ATo: 6lowpan@ietf.org=0ACc: Carsten Bormann =0ASent: Monday, March 19, 2007 10:55:42 AM=0ASubject: [6lowpan] Proposal= for DISCUSS Editorials=0A=0AI'm proposing the following disposition of the= editorial IESG =0Acomments that weren't in my previous message.=0AAgain, = quick feedback is useful.=0A=0AGruesse, Carsten=0A=0A=0A###################= ##############=0A* Editorial 1=0A=0A From Gen-ART review by Joel Halpern:= =0A=0A I don't know that I have ever seen a document before that = =0Asays "thou=0Ashalt not extend this." (Section 5, last sentence before 5= .1, "All =0Aheaders used=0Ain LOWPAN adaptation layer SHALL be defined in = this format document.")=0A=0A=3D=3D=3D> INTERPRET COMMENT=0AMy view of this= is that this is indeed the intention. Of course,=0Aevolving this spec itse= lf should be possible. Note that this would=0Arequire some version managem= ent, which will need to be addressed by=0Abootstrapping.=0A=0Agab> sounds f= ine as a response to Joel.=0A=0A#################################=0A* Edito= rial 2=0A=0A The fragmentation technique sends an offset that is in= =0Amultiple of 8=0Abytes. It would be sensible to say that all fragments= except the =0Alast SHOULD=0A(MUST?) be multiple of eight bytes, so that t= he fragment offset works =0Awell.=0A(section 5.3)=0A=0A=3D=3D=3D> ACCEPT C= OMMENT AND CHANGE TEXT=0AOLD:=0A If an entire payload (e.g., IPv6) datag= ram fits within a single=0A 802.15.4 frame, it is unfragmented and the L= oWPAN encapsulation=0A should contain no fragmentation header. If the d= atagram does not =0Afit=0A within a single IEEE 802.15.4 frame, it SHAL= L be broken into link=0A fragments. The first link fragment SHALL conta= in the first fragment=0A header (defined by one-bit as the first two bit= s and a zero-bit as=0A the third bit) shown below.=0A=0ANEW:=0A If an= entire payload (e.g., IPv6) datagram fits within a single=0A 802.15.4 f= rame, it is unfragmented and the LoWPAN encapsulation=0A should contain = no fragmentation header. If the datagram does not =0Afit=0A within a s= ingle IEEE 802.15.4 frame, it SHALL be broken into link=0A fragments. A= s the fragment offset can only express multiples of=0A eight bytes, all = link fragments for a datagram except the last one=0A MUST be multiples o= f eight bytes in length.=0A The first link fragment SHALL contain the fi= rst fragment=0A header (defined by one-bit as the first two bits and a z= ero-bit as=0A the third bit) shown below.=0A=0A(This is a new MUST, but = sensible implementations would have discarded=0Anon-aligned non-final fragm= ents anyway because of the non-overlap =0Amandate.)=0A=0Agab> I got rid of= the "one-bit" and "zero-bit" business, as now there are more bits than tha= t,=0Aand just said "as defined below". The relevant section now looks like = this:=0A=0A fragments. As the fragment offset can only express multiples= of=0A eight bytes, all link fragments for a datagram except the last one= =0A MUST be multiples of eight bytes in length. The first link fragment= =0A SHALL contain the first fragment header defined as shown below.=0A=0A= 1 2 3=0A = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A |= 1 1 0 0 0| datagram_size | datagram_tag |=0A +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=0A = Figure 10: First Fragment=0A############################= #####=0A* Editorial 3=0A=0A At the beginning of section 10.1 on Enc= oding IPv6 Header =0Afields, the=0Awording is slightly misleading. The wo= rding says "The following =0Acommon IPv6=0Aheader values may be compressed= from the onset..." I would suggest =0Ainstead "The=0Afollowing IPv6 head= er values are expected to be common on 6lowPan =0Anetworks, so=0Athe HC1 h= eader has been constructed to efficiently compress them from =0Athe=0Aonse= t."=0A=0A=3D=3D=3D> ACCEPT COMMENT AND CHANGE TEXT=0AOLD:=0A By virtue o= f having joined the same 6LoWPAN network, devices share=0A some state. = This makes it possible to compress headers even in the=0A absence of the= customary context-building phase. Thus, the =0Afollowing=0A common IP= v6 header values may be compressed from the onset: Version=0A ...=0ANEW:= =0A By virtue of having joined the same 6LoWPAN network, devices share= =0A some state. This makes it possible to compress headers without=0A = explicitly building any compression context state; 6lowpan header=0A c= ompression therefore does not keep any flow state, but relies=0A entirel= y on information pertaining to the entire link. The =0Afollowing=0A IP= v6 header values are expected to be common on 6lowPan networks,=0A so th= e HC1 header has been constructed to efficiently compress them=0A from t= he onset: Version=0A ...=0A=0Agab> Ok. Relevant section now looks like t= his:=0A=0A By virtue of having joined the same 6LoWPAN network, devices s= hare=0A some state. This makes it possible to compress headers without= =0A explicitly building any compression context state. Therefore,=0A 6= LoWPAN header compression does not keep any flow state. Instead, it=0A r= elies on information pertaining to the entire link. The following=0A IPv= 6 header values are expected to be common on 6LoWPAN networks, so=0A the = HC1 header has been constructed to efficiently compress them from=0A the = onset: Version is IPv6; both IPv6 source and destination=0A=0A#############= ####################=0A* Editorial 4=0A=0ADan Romascanu:=0A=0AComment [2007= -03-05]:=0AThe following two Informative References do not seem to be used:= =0A=0A [I-D.ietf-ipngwg-icmp-v3]=0A Conta, A., "Internet = Control Message Protocol (ICMPv6) =0Afor=0A the Internet Pro= tocol Version 6 (IPv6) Specification",=0A draft-ietf-ipngwg-= icmp-v3-07 (work in progress),=0A July 2005.=0A=0A [I-D.ie= tf-ipv6-node-requirements]=0A Loughney, J., "IPv6 Node Requir= ements",=0A draft-ietf-ipv6-node-requirements-11 (work in pro= gress),=0A August 2004.=0A=0A=3D=3D=3D> REMOVE UNUSED REFEREN= CES=0A=0Agab> Done. Ran it through IDNits, nothing further found.=0A=0A####= #############################=0A* Editorial 5=0A=0AComment [2007-03-06]:=0A= Section 3, last paragrpah:=0AThe working group may pursue additional=0A = mechanisms as well.=0A=0AIs this the right document to state a possible dir= ection of a WG?=0A=0A=3D=3D=3D> REMOVE SENTENCE=0A=0ADone already.=0A=0A###= ##############################=0A* HC editorial complex=0A=0AMagnus Westerl= und:=0A=0ADiscuss [2007-03-08]:=0A=0ASection 10.1:=0A=0A By virtue of ha= ving joined the same 6LoWPAN network, devices share=0A some state. This= makes it possible to compress headers even in the=0A absence of the cus= tomary context-building phase. Thus, the following=0A common IPv6 header= values may be compressed from the onset: Version=0A is IPv6; both IPv6 = source and destination addresses are link local;=0A the IPv6 interface i= dentifiers (bottom 64 bits) for the source or=0A destination addresses c= an be inferred from the layer two source and=0A destination addresses (o= f course, this is only possible for =0Ainterface=0A identifiers derived= from an underlying 802.15.4 MAC address); the=0A packet length can be i= nferred either from layer two ("Frame Length"=0A in the IEEE 802.15.4 PP= DU) or from the "datagram_size" field in the=0A fragment header (if pres= ent); both the Traffic Class and the Flow=0A Label are zero; and the Nex= t Header is UDP, ICMP or TCP.=0A=0ACurrently this is written such as that o= ne get the impression that these=0Aassumptions always will be true. Instead= as it seems it should be =0Ainterpret, in=0Acase the fields has the follo= wing values gains in HC can be made.=0A=0A=3D=3D=3D> SEE EDITORIAL 3 ABOVE.= COVERED.=0A=0Agab> Ok.=0A=0AThe text is also confusing the reader if ther= e exist a context state =0Aor not.=0AFor example:=0A=0A Preliminary = context is often required. If so, it is highly=0A desirable to allow= building it by not relying exclusively on the=0A in-line negotiation= phase. For example, if we assume there is=0A some manual configurat= ion phase that precedes deployment (perhaps=0A with human involvement= ), then one should be able to leverage this=0A phase to set up contex= t such that the first packet sent will=0A already be compressed.=0A= =0A=3D=3D=3D> STRIKE THIS PARAGRAPH.=0A=0Agab> Done.=0A=0AThere is also con= fusion about if several flows can be handled. =0APrimarily due to=0Athe fo= llowing:=0A=0A Existing work assumes that there are many flows betwee= n any two=0A devices. Here, we assume that most of the time there wi= ll be =0Aonly=0A one flow, and this allows a very simple and low con= text flavor of=0A header compression.=0A=0A=3D=3D=3D> STRIKE PARAGRAP= H=0A=0Agab> In my response to Magnus yesterday, I suggested some modified t= ext. Since Magnus =0Aalready ok-ed that text previous to your message, I wi= ll keep it. The modified text is as follows:=0A=0A Existing work assum= es that there are many flows between any two=0A devices. Here, we ass= ume a very simple and low-context flavor of=0A header compression. Wh= ereas this works independently of flows=0A (potentially several), it d= oes not use any context specific to any=0A flow. Thus, it cannot achi= eve as much compression as usual flow-=0A aware schemes=0A=0APlease cl= arify that the compression is done totally without context =0Aand thus=0Ac= an handle any number of flows.=0A=0A=3D=3D=3D> COVERED (EDITORIAL 3 ABOVE)= =0A=0Agab> Ok.=0A=0ASection 10.=0A=0AUnfortuntate that this document wasn't= announced on the ROHC WG list =0Aduring its=0AWGL last call. Based on tha= t the description seems somewhat to thin =0Ato be easily=0Aimplementable. = I would propose that we delay the approval, update the =0Adraft and=0Asend= it for an explicit review in ROHC.=0A=0A=3D=3D=3D> SORRY. ROHC WG WAS AWA= RE ABOUT 6LOWPAN, BUT IT SHOULD HAVE BEEN=0A ALERTED EXPLICITLY. HARD= TO FIX NOW. NO NEED TO WAIT, THOUGH.=0A=0Agab> Please respond to Magnus a= bout this, as he insisted on this point in his response to my message.=0A= =0ALars Eggert:=0A=0AComment [2007-03-07]:=0AAgree with Magnus' points abou= t the header compression specification.=0A=0A=3D=3D=3D> COVERED (ABOVE).=0A= =0Agab> Ok.=0A=0A=0A_______________________________________________=0A6lowp= an mailing list=0A6lowpan@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo= /6lowpan=0A=0A=0A=0A=0A --0-594892295-1174374891=:19586 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
inline marked "gab>"

----- Original = Message ----
From: Carsten Bormann <cabo@tzi.org>
To: 6lowpan@i= etf.org
Cc: Carsten Bormann <cabo@tzi.org>
Sent: Monday, March = 19, 2007 10:55:42 AM
Subject: [6lowpan] Proposal for DISCUSS Editorials<= br>
I'm proposing the following disposition of the editorial IESG&n= bsp; 
comments that weren't in my previous message.
Again, quick= feedback is useful.

Gruesse, Carsten


###################= ##############
* Editorial 1

From Gen-ART review by Joel Halpern= :

         I don't know that= I have ever seen a document before that  
says "thou
shalt not extend this."&= nbsp; (Section 5, last sentence before 5.1, "All  
header= s used
in LOWPAN adaptation layer SHALL be defined in this format docume= nt.")

=3D=3D=3D> INTERPRET COMMENT
My view of this is that thi= s is indeed the intention. Of course,
evolving this spec itself should b= e possible.  Note that this would
require some version managem= ent, which will need to be addressed by
bootstrapping.

gab> so= unds fine as a response to Joel.

#################################* Editorial 2

         The= fragmentation technique sends an offset that is in  
multiple= of 8
bytes.  It would be sensible to say that all fragments e= xcept the  
last SHOULD
(MUST?) be multiple of eight bytes,= so that the fragment offset works  
well.
(section 5.3)
=3D=3D=3D> ACCEPT COMMENT AND CHANGE TEXT
OLD:
    If an entire pa= yload (e.g., IPv6) datagram fits within a single
    = ;802.15.4 frame, it is unfragmented and the LoWPAN encapsulation
 &= nbsp;  should contain no fragmentation header.  If the = datagram does not  
fit
    within a si= ngle IEEE 802.15.4 frame, it SHALL be broken into link
   = ; fragments.  The first link fragment SHALL contain the firs= t fragment
    header (defined by one-bit as the fir= st two bits and a zero-bit as
    the third bit) sho= wn below.

NEW:
    If an entire payload (e.g.= , IPv6) datagram fits within a single
    802.15.4 f= rame, it is unfragmented and the LoWPAN encapsulation
   =  should contain no fragmentation header.  If the datagram do= es not  
fit
    within a single IEEE 802= .15.4 frame, it SHALL be broken into link
    fragme= nts.  As the fragment offset can only express multiples of
&nb= sp;   eight bytes, all link fragments for a datagram except = the last one
    MUST be multiples of eight bytes in= length.
    The first link fragment SHALL contain t= he first fragment
    header (defined by one-bit as = the first two bits and a zero-bit as
    the third b= it) shown below.

(This is a new MUST, but sensible implementations w= ould have discarded
non-aligned non-final fragments anyway because of th= e non-overlap  
mandate.)

gab> I got rid of the "one= -bit" and "zero-bit" business, as now there are more bits than that,
and= just said "as defined below". The relevant section now looks like this:
 =20
 fragments.  As the fragment offset can only express multiples of
   eig=
ht bytes, all link fragments for a datagram except the last one
   MUST =
be multiples of eight bytes in length.  The first link fragment
   SHALL=
 contain the first fragment header defined as shown below.

         =
                  1                   2                   3
       0 1 2=
 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 0 =
0 0|    datagram_size    |         datagram_tag          |
      +-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         =
                Figure 10: First Fragment

########################= #########
* Editorial 3

       = ;  At the beginning of section 10.1 on Encoding IPv6 Header  = ;
fields, the
wording is slightly misleading.  The wording = says "The following  
common IPv6
header values may be compressed fr= om the onset..."  I would suggest  
instead "The
= following IPv6 header values are expected to be common on 6lowPan &nbs= p;
networks, so
the HC1 header has been constructed to efficiently co= mpress them from  
the
onset."

=3D=3D=3D> ACCEPT = COMMENT AND CHANGE TEXT
OLD:
    By virtue of hav= ing joined the same 6LoWPAN network, devices share
   &nb= sp;some state.  This makes it possible to compress headers even i= n the
    absence of the customary context-building = phase.  Thus, the  
following
   &= nbsp;common IPv6 header values may be compressed from the onset: Version    ...
NEW:
    By virtue o= f having joined the same 6LoWPAN network, devices share
  &nbs= p; some state.  This makes it possible to compress headers without
&n= bsp;   explicitly building any compression context state; 6l= owpan header
    compression therefore does not keep= any flow state, but relies
    entirely on informat= ion pertaining to the entire link.  The  
following<= br>    IPv6 header values are expected to be common on = 6lowPan networks,
    so the HC1 header has been con= structed to efficiently compress them
    from the o= nset: Version
    ...

gab> Ok. Relevant se= ction now looks like this:

   By virtue of having joined the sa=
me 6LoWPAN network, devices share
   some state.  This makes it possible=
 to compress headers without
   explicitly building any compression cont=
ext state.  Therefore,
   6LoWPAN header compression does not keep any f=
low state.=20
 Instead, it
   relies on information pertaining to the entire link.  Th=
e following
   IPv6 header values are expected to be common on 6LoWPAN n=
etworks, so
   the HC1 header has been constructed to efficiently compre=
ss them from
   the onset: Version is IPv6; both IPv6 source and destina=
tion


#################################
* Editorial 4
Dan Romascanu:

Comment [2007-03-05]:
The following two Informati= ve References do not seem to be used:

     [I-D.= ietf-ipngwg-icmp-v3]
        &nb= sp;      Conta, A., "Internet Control Message Prot= ocol (ICMPv6)  
for
      &nb= sp;        the Internet Protocol Version=   6 (IPv6) Specification",
      = ;         draft-ietf-ipngwg-icmp-v3= -07 (work in progress),
          =      July 2005.

    [I-D.iet= f-ipv6-node-requirements]
       &nbs= p;       Loughney, J., "IPv6 Node Requirement= s",
           &n= bsp;   draft-ietf-ipv6-node-requirements-11 (work in progress),            &= nbsp;  August 2004.

=3D=3D=3D> REMOVE UNUSED REFERENCES
<= br>gab> Done. Ran it through IDNits, nothing further found.

#####= ############################
* Editorial 5

Comment [2007-03-06]:<= br>Section 3, last paragrpah:
The working group may pursue additional    mechanisms as well.

Is this the right docum= ent to state a possible direction of a WG?

=3D=3D=3D> REMOVE SENT= ENCE

Done already.

#################################
* HC editorial comple= x

Magnus Westerlund:

Discuss [2007-03-08]:

Section 10.= 1:

    By virtue of having joined the same 6LoWP= AN network, devices share
    some state.  = ;This makes it possible to compress headers even in the
  &nbs= p; absence of the customary context-building phase. Thus, the followin= g
    common IPv6 header values may be compressed fr= om the onset: Version
    is IPv6; both IPv6 source = and destination addresses are link local;
    the IP= v6 interface identifiers (bottom 64 bits) for the source or
  =   destination addresses can be inferred from the layer two source= and
    destination addresses (of course, this is o= nly possible for  
interface
    identi= fiers derived from an underlying 802.15.4 MAC address); the
    p= acket length can be inferred either from layer two ("Frame Length"
 = ;   in the IEEE 802.15.4 PPDU) or from the "datagram_size" f= ield in the
    fragment header (if present); both t= he Traffic Class and the Flow
    Label are zero; an= d the Next Header is UDP, ICMP or TCP.

Currently this is written suc= h as that one get the impression that these
assumptions always will be t= rue. Instead as it seems it should be  
interpret, in
case = the fields has the following values gains in HC can be made.

=3D=3D= =3D> SEE EDITORIAL 3 ABOVE.  COVERED.

gab> Ok.
The text is also confusing the reader if there exist a context state = ; 
or not.
For example:

     &nb= sp; Preliminary context is often required.  If so, it is highly
       desirable to allow building= it by not relying exclusively on the
     &nbs= p; in-line negotiation phase.  For example, if we assume there is=
       some manual configuration phase th= at precedes deployment (perhaps
       wit= h human involvement), then one should be able to leverage this
 &nb= sp;     phase to set up context such that the first pac= ket sent will
       already be compressed= .

=3D=3D=3D> STRIKE THIS PARAGRAPH.

gab> Done.

T= here is also confusion about if several flows can be handled.  Primarily due to
the following:

     &= nbsp; Existing work assumes that there are many flows between any two
&n= bsp;      devices.  Here, we assume that= most of the time there will be  
only
       = one flow, and this allows a very simple and low context flavor of
 =       header compression.

=3D=3D=3D> STR= IKE PARAGRAPH

gab> In my response to Magnus yesterday, I suggeste= d some modified text. Since Magnus
already ok-ed that text previous to = your message, I will keep it. The modified text is as follows:

=
      Existing work assumes that there are many flows between any two
  =
    devices.  Here, we assume a very simple and low-context flavor of
  =
    header compression.  Whereas this works independently of flows
     =
 (potentially several), it does not use any context specific to any
    =
  flow.  Thus, it cannot achieve as much compression as usual flow-
    =
  aware schemes


Please clarify that the compression is done to= tally without context  
and thus
can handle any number of flows.

=3D=3D=3D> COVERED (EDITORIAL 3 ABOVE)

gab> Ok.=

Section 10.

Unfortuntate that this document wasn't announced= on the ROHC WG list  
during its
WGL last call. Based on t= hat the description seems somewhat to thin  
to be easily
i= mplementable. I would propose that we delay the approval, update the &= nbsp;
draft and
send it for an explicit review in ROHC.

=3D=3D= =3D> SORRY.  ROHC WG WAS AWARE ABOUT 6LOWPAN, BUT IT SHOULD HA= VE BEEN
      ALERTED EXPLICITLY. &nb= sp;HARD TO FIX NOW.  NO NEED TO WAIT, THOUGH.

gab> Plea= se respond to Magnus about this, as he insisted on this point in his respon= se to my message.

Lars Eggert:

Comment [2007-03-07]:
Agree= with Magnus' points about the header compression specification.

=3D= =3D=3D> COVERED (ABOVE).

gab> Ok.


_______________________________________________
6lowpan = mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinf= o/6lowpan

--0-594892295-1174374891=:19586-- --===============1979125703== 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 --===============1979125703==-- From 6lowpan-bounces@ietf.org Tue Mar 20 03:21:02 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYeU-0003hr-Be; Tue, 20 Mar 2007 03:21:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYeT-0003hX-CH for 6lowpan@ietf.org; Tue, 20 Mar 2007 03:21:01 -0400 Received: from web81905.mail.mud.yahoo.com ([68.142.207.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTYaZ-0005mf-DH for 6lowpan@ietf.org; Tue, 20 Mar 2007 03:17:10 -0400 Received: (qmail 3260 invoked by uid 60001); 20 Mar 2007 07:16:58 -0000 Message-ID: <20070320071658.3258.qmail@web81905.mail.mud.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=X32mBT8TWz9qtxJGkekvgmUd4BsceDOpQqAalZRgZfrI8diek9aUGW/CZ+GWBS4/VKdOo0YBgFm1JP9MwNfEZnDlsyYF8IUrflPGm1Jh/tz2MmAurkJs08+ebIzEboJ6zYFpwYqcuW7+l/j37R5Jph4PlrmqxFHXiJjCjYJI3YA=; X-YMail-OSG: ha0_jo0VM1l2.R8ScMo_spINsC5.vlYakL_4GabY59N2UhdPtUqiHD.8FnOfYZutOcIHppicMKRBHXb0ku9AKJc6m8QOUBv3P6MH7zHART3yCA6HfeoIIqsblYnDWYtUMGWPP1cqvlM- Received: from [131.107.0.103] by web81905.mail.mud.yahoo.com via HTTP; Tue, 20 Mar 2007 00:16:58 PDT X-Mailer: YahooMailRC/368.8 YahooMailWebService/0.6.132.8 Date: Tue, 20 Mar 2007 00:16:58 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] post-IETF-last-call fix: Fixing the value of P To: Carsten Bormann , 6lowpan@ietf.org, Mark Townsley MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f 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="===============0548280286==" Errors-To: 6lowpan-bounces@ietf.org --===============0548280286== Content-Type: multipart/alternative; boundary="0-856803061-1174375018=:99686" --0-856803061-1174375018=:99686 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I've applied this change to the temporary rev 12.=0A=0AI do note that Yoshi= ko Chang already sent the IANA response on March 14 with the understanding = that this number P was to be assigned =0Aby them.=0A=0AWe should proactivel= y let them know that this has changed (once we officially submit rev 12). C= C-ing Mark to make sure =0Ahe's in the loop concerning this IANA "un-action= ".=0A=0A-gabriel=0A=0A=0A=0A----- Original Message ----=0AFrom: Carsten Bor= mann =0ATo: 6lowpan@ietf.org=0ACc: Carsten Bormann =0ASent: Monday, March 19, 2007 6:10:14 AM=0ASubject: [6lowpan] post-IE= TF-last-call fix: Fixing the value of P=0A=0ASection 10.2 of the format doc= ument defines the value of P as=0A "TBD", =0Awaiting for IANA assignment, = and section 12 accordingly states:=0A=0A This document requests an IANA = assignment of a port number P, for =0Ause=0A with UDP header compressio= n (Section 10.2). This port number P is=0A used as the base to which th= e "short_port" 4-bit values are added in=0A order to obtain the actual U= DP port used.=0A=0AThis has raised a DISCUSS from the IESG, and from the di= scussion the =0Athe 6lowpan meeting today, it is clear that this is incorr= ect.=0A=0AThere is no intention to actually allocate a port for a specific = =0Aprotocol (and if there were, we should be allocating 16 ports in =0Ase= quence, which would require some justification).=0A=0AInstead, the UDP head= er compression mechanism just causes port =0Anumbers from the range [P..P+= 15] to be compressed better=0A than other =0AUDP port nunbers.=0A=0AExperi= ence with managing small number spaces (cf. Payload Types in =0ARTP) sugge= sts this space would not be allocated one-by-one to =0Aapplications, but i= t should be a dynamic space. Indeed, there is no =0Aneed to "reserve" the= port numbers in the [P..P+15] range -- =0Areceivers are free to put their= listeners there and senders are free =0Ato use these ports as the source = ports.=0A=0AThe IANA allocated port number space already has already alloca= ted =0A16384 ports for dynamic use, we don't need a new allocation.=0AThe = result of the meeting was that the [P..P+15] space should simply =0Abe som= ewhere in this space. We just need to pick a P between 49152 =0Aand 65520= .=0AA highly scientific process run in the meeting room after the close = =0Aof the meeting resulted in the choice of 61616 (0xF0B0)=0A as a good = =0Avalue for P.=0A=0AAs a result, I propose the fix below as an expression = of the meeting =0Aconsensus.=0A=0AWe now need to know quickly whether ther= e is any problem with this =0Aminor change.=0A=0AGruesse, Carsten=0A=0A=0A= =0AChange the text in 10.2 as follows:=0A=0AOLD:=0A UDP source port (= bit 0):=0A 0: Not compressed, carried "in-line" (Section 10.3.2)= =0A 1: Compressed to 4 bits. The actual 16-bit source port is=0A = obtained by calculating: P + short_port value. P is a=0A = predetermined port number with value TBD. The =0Ashort_port=0A is= =0A expressed as a 4-bit value which is carried "in-line"=0A = (Section 10.3.2)=0A=0A UDP destination port (bit 1):=0A = 0: Not compressed, carried "in-line" (Section 10.3.2)=0A 1: = Compressed to 4 bits. The actual 16-bit destination =0Aport is=0A = obtained by calculating: P + short_port value. P is a=0A = predetermined port number with value TBD. The =0Ashort_port is=0A = expressed as a 4-bit value which is=0A carried "in-line"=0A = (Section 10.3.2)=0A=0ANEW:=0A UDP source port (bit 0):=0A = 0: Not compressed, carried "in-line" (Section 10.3.2)=0A 1: Compre= ssed to 4 bits. The actual 16-bit source port is=0A obtained b= y calculating: P + short_port value. The value=0A of P is the = number 61616 (0xF0B0). The short_port is=0A expressed as a 4-b= it value which is carried "in-line"=0A (Section 10.3.2)=0A=0A = =0A UDP destination port (bit 1):=0A 0: Not compressed, carrie= d "in-line" (Section 10.3.2)=0A 1: Compressed to 4 bits. The actu= al 16-bit destination =0Aport is=0A obtained by calculating: P= + short_port value. The value=0A of P is the number 61616 (0x= F0B0). The short_port is=0A expressed as a 4-bit value which i= s carried "in-line"=0A (Section 10.3.2)=0A=0A=0AIn 12, strike:= =0A=0AOLD:=0A This document requests an IANA assignment of a port number= P, for =0Ause=0A with=0A UDP header compression (Section 10.2). This = port number P is=0A used as the base to which the "short_port" 4-bit val= ues are added in=0A order to obtain the actual UDP port used.=0A=0ANEW: = (no replacement text).=0A=0A_______________________________________________= =0A6lowpan mailing list=0A6lowpan@ietf.org=0Ahttps://www1.ietf.org/mailman/= listinfo/6lowpan=0A=0A=0A=0A=0A=0A --0-856803061-1174375018=:99686 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I've applied this change to the temporary rev = 12.

I do note that Yoshiko Chang already sent the IANA response on M= arch 14 with the understanding that this number P was to be assigned
by= them.

We should proactively let them know that this has changed (on= ce we officially submit rev 12). CC-ing Mark to make sure
he's in the l= oop concerning this IANA "un-action".

-gabriel



waiting for IANA assignment, and section= 12 accordingly states:

    This document reques= ts an IANA assignment of a port number P, for  
use
 &= nbsp;  with UDP header compression (Section 10.2).  Thi= s port number P is
    used as the base to which the= "short_port" 4-bit values are added in
    order to= obtain the actual UDP port used.

This has raised a DISCUSS from the= IESG, and from the discussion the  
the 6lowpan meeting today= , it is clear that this is incorrect.

There is no intention to actua= lly allocate a port for a specific  
protocol (and if there we= re, we should be allocating 16 ports in  
sequence, which woul= d require some justification).

Instead, the UDP header compression m= echanism just causes port  
numbers from the range [P..P+15] t= o be compressed better=0A than other  
UDP port nunbers.
Experience with managing small number spaces (cf. Payload Types in &= nbsp;
RTP) suggests this space would not be allocated one-by-one to = ; 
applications, but it should be a dynamic space.  Indee= d, there is no  
need to "reserve" the port numbers in the [P.= .P+15] range --  
receivers are free to put their listeners th= ere and senders are free  
to use these ports as the source po= rts.

The IANA allocated port number space already has already alloca= ted  
16384 ports for dynamic use, we don't need a new allocat= ion.
The result of the meeting was that the [P..P+15] space should simpl= y  
be somewhere in this space.  We just need to pic= k a P between 49152  
and 65520.
A highly scientific proces= s run in the meeting room after the close  
of the meeting res= ulted in the choice of 61616 (0xF0B0)=0A as a good  
value for= P.

As a result, I propose the fix below as an expression of the mee= ting  
consensus.

We now need to know quickly whether t= here is any problem with this  
minor change.

Gruesse, = Carsten



Change the text in 10.2 as follows:

OLD:
&= nbsp;      UDP source port (bit 0):
  = ;        0: Not compressed, carried= "in-line" (Section 10.3.2)
       &n= bsp;  1: Compressed to 4 bits.  The actual 16-bit sourc= e port is
          &n= bsp;  obtained by calculating: P + short_port value.  P is a=
            = ; predetermined port number with value TBD.  The  
s= hort_port=0A is
         &n= bsp;   expressed as a 4-bit value which is carried "in-line"
&= nbsp;            (Se= ction 10.3.2)

       UDP destination p= ort (bit 1):
          = ;0: Not compressed, carried "in-line" (Section 10.3.2)
   = ;       1: Compressed to 4 bits. &n= bsp;The actual 16-bit destination  
port is
  &nb= sp;          obtained by calcu= lating: 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=0A carried "in-line"
     = ;        (Section 10.3.2)

NEW:       UDP source port (bit 0):
 &nb= sp;        0: Not compressed, carri= ed "in-line" (Section 10.3.2)
       =    1: Compressed to 4 bits.  The actual 16-bit sou= rce port is
          =    obtained by calculating: P + short_port value.  The = value
           =   of P is the number 61616 (0xF0B0).  The short_port is
&= nbsp;            exp= ressed as a 4-bit value which is carried "in-line"
   &nb= sp;         (Section 10.3.2)
      =0A UDP destination port (bit 1):
&= nbsp;         0: Not compresse= d, carried "in-line" (Section 10.3.2)
     &nbs= p;    1: Compressed to 4 bits.  The actual 16= -bit destination  
port is
     &n= bsp;       obtained by calculating: P + short= _port value.  The value
      &n= bsp;      of P is the number 61616 (0xF0B0). =  The short_port is
        =      expressed as a 4-bit value which is carried "in-li= ne"
           &n= bsp; (Section 10.3.2)


In 12, strike:

OLD:
  =   This document requests an IANA assignment of a port number P, f= or  
use
    with=0A UDP header compres= sion (Section 10.2).  This port number P is
   =  used as the base to which the "short_port" 4-bit values are added in<= br>    order to obtain the actual UDP port used.
NEW: (no replacement text).

_______________________________________= ________
6lowpan mailing list
6lowpan@ietf.org
= https://www1.ietf.org/mailman/listinfo/6lowpan

--0-856803061-1174375018=:99686-- --===============0548280286== 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 --===============0548280286==-- From 6lowpan-bounces@ietf.org Tue Mar 20 03:30:02 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYn0-0000YO-6x; Tue, 20 Mar 2007 03:29:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYmz-0000YJ-E4 for 6lowpan@ietf.org; Tue, 20 Mar 2007 03:29:49 -0400 Received: from web81903.mail.mud.yahoo.com ([68.142.207.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTYmy-00077w-5U for 6lowpan@ietf.org; Tue, 20 Mar 2007 03:29:49 -0400 Received: (qmail 28990 invoked by uid 60001); 20 Mar 2007 07:29:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=yOFtPS1i9p5BjP7ooBYSRhkAUQdtCQrmdzJWHyi+bkqSjp3qhnK/2tu5wF361WCxzgmXa5Y8PndCqB60WE3cC3IO9VZml27BdKarqFsT4gy9eDCWilaiT4GrekYcCB1gFg7KXSn9+trFJjrgnBqfVF3cfFWouWtnT1rbiaFJXhQ=; X-YMail-OSG: bM6zqwwVM1n0erIykvZZ7BrMz6wcQmKSRqbifChFN2rWepW8up8X.O9tsN4acsUE5kqXRndmAqFt0Y1gTOjDxgpK_j.H1hE4146WfjewULm31wWyldxlzo0ngjDSHySA71knG9Uxmhbxwtcmfw.FBTvItJ1LU0wDtDkfNsBuWLGhFAmvyK2ukWuDx2owDUE1o.Z9LA-- Received: from [131.107.0.103] by web81903.mail.mud.yahoo.com via HTTP; Tue, 20 Mar 2007 00:29:47 PDT X-Mailer: YahooMailRC/368.8 YahooMailWebService/0.6.132.8 Date: Tue, 20 Mar 2007 00:29:47 -0700 (PDT) From: gabriel montenegro To: 6lowpan@ietf.org, 6lowpan-chairs@tools.ietf.org MIME-Version: 1.0 Message-ID: <733445.22863.qm@web81903.mail.mud.yahoo.com> X-Spam-Score: 1.0 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [6lowpan] tentative rev 12 format draft: draft-ietf-6lowpan-format-12.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: , Content-Type: multipart/mixed; boundary="===============0975915747==" Errors-To: 6lowpan-bounces@ietf.org --===============0975915747== Content-Type: multipart/alternative; boundary="0-784105203-1174375787=:22863" --0-784105203-1174375787=:22863 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Chairs,=0A=0AI've modified the draft to address IESG comments based on rece= nt exchanges, and created a tentative version 12 available at:=0A=0A htt= p://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-12.= txt=0A=0AChairs, please double check and submit if it's fine.=0A=0A-gabriel= =0A=0A --0-784105203-1174375787=:22863 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Chairs,

I've modified the draft to address IESG co= mments based on recent exchanges, and created a tentative version 12 availa= ble at:

    Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbDD-0001qL-Cz; Tue, 20 Mar 2007 06:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbDC-0001qB-L8 for 6lowpan@ietf.org; Tue, 20 Mar 2007 06:05:02 -0400 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbCu-00041D-2h for 6lowpan@ietf.org; Tue, 20 Mar 2007 06:05:02 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l2KA4evQ022893; Tue, 20 Mar 2007 11:04:40 +0100 (CET) In-Reply-To: <45FF8F2B.4040604@cisco.com> References: <20070320071658.3258.qmail@web81905.mail.mud.yahoo.com> <45FF8F2B.4040604@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5859712E-042F-4205-A07F-76F3C4B2F1D6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [6lowpan] post-IETF-last-call fix: Fixing the value of P Date: Tue, 20 Mar 2007 11:04:38 +0100 To: Mark Townsley X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Carsten Bormann , 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 > Do you *really* want to start with 61616?? I know you like the > number "6" and this is really cute (or nearly evil, depending on > your belief in strict interpretation of some religious texts) but > doesn't it make sense to start with something that is not easy to > remember, mentally add to, etc? This number may very well end up as > a hand-configuration item in some application that runs over UDP > which happens to be on a 6lowpan, and defining a *range* (e.g. not > just focusing on "P") that is easy to recognize and remember would > seem to be prudent. > > Something like 60000 - 60015 ? We tried to avoid the "obvious" numbers, because these numbers often are picked by protocol designers that don't know about IANA. (cf. 6000, 5900, 5500, ...) 6l(owpan) almost reads like 61, so this was the way we arrived at the pseudo-random number (we also wanted to make sure it is == 0 modulo 16). So the range would be 61616 to 61631, 0xF0B0 to 0xF0BF. 61600 to 61615 (0xF0A0 to 0xF0AF) would do, too, but is slightly less memorable (this has nothing to do with FOAF, either...). As usual for this class of problems, I don't really care, so anyone who feels strongly about this gets to pick the number. Gruesse, Carsten PS.: Picking inconsequential numbers is such fun... http://www.bikeshed.com :-) _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 20 06:22:53 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbUH-0006hh-2R; Tue, 20 Mar 2007 06:22:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbUF-0006XW-91 for 6lowpan@ietf.org; Tue, 20 Mar 2007 06:22:39 -0400 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTbUA-0002tT-JC for 6lowpan@ietf.org; Tue, 20 Mar 2007 06:22:39 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l2KAMMJh009753; Tue, 20 Mar 2007 11:22:22 +0100 (CET) In-Reply-To: <733445.22863.qm@web81903.mail.mud.yahoo.com> References: <733445.22863.qm@web81903.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [6lowpan] tentative rev 12 format draft: draft-ietf-6lowpan-format-12.txt Date: Tue, 20 Mar 2007 11:22:20 +0100 To: gabriel montenegro X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Carsten Bormann , 6lowpan@ietf.org, 6lowpan-chairs@tools.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 Mar 20 2007, at 08:29, gabriel montenegro wrote: > Chairs, > > I've modified the draft to address IESG comments based on recent > exchanges, and created a tentative version 12 available at: > > http://www.geocities.com/gabriel_montenegro_2000/draft- > ietf-6lowpan-format-12.txt Looks good to me. Thanks for catching the "one-bit" remnant. I'd rather have deleted the first indented paragraph of the justifying text starting 10. If we keep it, please add a full stop at the end of "usual flow- aware schemes" (or maybe turn it into something more readable, such as "schemes that build separate context for each flow to be compressed"). The one remaining comment not covered is the justifying text under "datagram size", for which Jari supplied a comment. I'd propose simply deleting the justification: > Typically, this field needs to encode a maximum length of 1280 > (IEEE 802.15.4 link MTU as defined in this document), and as much > as 1500 (the default maximum IPv6 packet size if IPv6 > fragmentation is in use). Therefore, this field is 11 bits long, > which works in either case. (If we had wanted to explain anything about this field, it should have been that this is *NOT* the datagram size, but the IPv6 packet size, i.e. the result of any IPv6 fragmentation that may already have happened.) Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 20 06:43:21 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbo3-0003Ed-74; Tue, 20 Mar 2007 06:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbo1-0003EW-LA for 6lowpan@ietf.org; Tue, 20 Mar 2007 06:43:05 -0400 Received: from [212.16.99.49] (helo=moth.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbo0-00062o-3e for 6lowpan@ietf.org; Tue, 20 Mar 2007 06:43:05 -0400 Received: from moth.iki.fi (msa@localhost [127.0.0.1]) by moth.iki.fi (8.13.8/8.13.8/Debian-3) with ESMTP id l2KAgWTF008110; Tue, 20 Mar 2007 12:42:35 +0200 Received: (from msa@localhost) by moth.iki.fi (8.13.8/8.13.8/Submit) id l2KAgWWD008107; Tue, 20 Mar 2007 12:42:32 +0200 Date: Tue, 20 Mar 2007 12:42:32 +0200 Message-Id: <200703201042.l2KAgWWD008107@moth.iki.fi> From: Markku Savela To: cabo@tzi.org In-reply-to: (message from Carsten Bormann on Tue, 20 Mar 2007 11:22:20 +0100) Subject: Re: [6lowpan] tentative rev 12 format draft: draft-ietf-6lowpan-format-12.txt References: <733445.22863.qm@web81903.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 6lowpan-chairs@tools.ietf.org, cabo@tzi.org, 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org > From: Carsten Bormann > > Typically, this field needs to encode a maximum length of 1280 > > (IEEE 802.15.4 link MTU as defined in this document), and as much > > as 1500 (the default maximum IPv6 packet size if IPv6 > > fragmentation is in use). Therefore, this field is 11 bits long, > > which works in either case. Uhh.. the max IPv6 packet size is over 65Kbytes! It's just that depending on MTU, it gets fragmented to smaller pieces on a specific interface/link. Thus, this MTU (and resulting IPv6 packet size) is whatever the 6lowpan decides to specify. And, of course, the TCP protocol stack tries to avoid fragmenting, and uses whatever size fits the MTU. But for UDP, the packet size is totally under application control (like Blackberry sometimes uses(?) 4-8Kb UDP packets). > (If we had wanted to explain anything about this field, it should > have been that this is *NOT* the datagram size, but the IPv6 packet > size, i.e. the result of any IPv6 fragmentation that may already have > happened.) _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 20 06:50:18 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbuz-0006gZ-Ki; Tue, 20 Mar 2007 06:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbuy-0006gT-NF for 6lowpan@ietf.org; Tue, 20 Mar 2007 06:50:16 -0400 Received: from [212.16.99.49] (helo=moth.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbuw-00072t-6i for 6lowpan@ietf.org; Tue, 20 Mar 2007 06:50:16 -0400 Received: from moth.iki.fi (msa@localhost [127.0.0.1]) by moth.iki.fi (8.13.8/8.13.8/Debian-3) with ESMTP id l2KAoDgl008284; Tue, 20 Mar 2007 12:50:13 +0200 Received: (from msa@localhost) by moth.iki.fi (8.13.8/8.13.8/Submit) id l2KAoDFL008281; Tue, 20 Mar 2007 12:50:13 +0200 Date: Tue, 20 Mar 2007 12:50:13 +0200 Message-Id: <200703201050.l2KAoDFL008281@moth.iki.fi> From: Markku Savela To: cabo@tzi.org, 6lowpan-chairs@tools.ietf.org, cabo@tzi.org, 6lowpan@ietf.org In-reply-to: <200703201042.l2KAgWWD008107@moth.iki.fi> (message from Markku Savela on Tue, 20 Mar 2007 12:42:32 +0200) Subject: Re: [6lowpan] tentative rev 12 format draft: draft-ietf-6lowpan-format-12.txt References: <733445.22863.qm@web81903.mail.mud.yahoo.com> <200703201042.l2KAgWWD008107@moth.iki.fi> X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 > From: Markku Savela > Thus, this MTU (and resulting IPv6 packet size) is whatever the > 6lowpan decides to specify. Occurs to me, as 6lowpan does it's own internal fragmentation anyway, it could actually advertise very large MTU (like 4-16Kb) to avoid IPv6 header overhead in bulk transfers. Whether sensible, depends how likely the packet loss is on the link. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 20 06:52:29 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbx7-000856-IN; Tue, 20 Mar 2007 06:52:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbx6-000806-Ks for 6lowpan@ietf.org; Tue, 20 Mar 2007 06:52:28 -0400 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTbx5-0000Du-61 for 6lowpan@ietf.org; Tue, 20 Mar 2007 06:52:28 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l2KAqPch008738; Tue, 20 Mar 2007 11:52:25 +0100 (CET) In-Reply-To: <200703201042.l2KAgWWD008107@moth.iki.fi> References: <733445.22863.qm@web81903.mail.mud.yahoo.com> <200703201042.l2KAgWWD008107@moth.iki.fi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [6lowpan] tentative rev 12 format draft: draft-ietf-6lowpan-format-12.txt Date: Tue, 20 Mar 2007 11:52:19 +0100 To: Markku Savela X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Carsten Bormann , 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 Mar 20 2007, at 11:42, Markku Savela wrote: > Uhh.. the max IPv6 packet size is over 65Kbytes! A couple of us may be aware of that (and even of Jumbograms) :-) Another reason to remove this text. (As a general rule, justifying text rarely is very useful in the body of a specification, and it often confuses more than it helps. Also, as in this case, apparently nobody cared to proofread it as it is just justifying the actual contents of the specification. It's like comments in programs; they are not tested and get out of date too quickly. Another textbook example for our classes on protocol design...) Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 20 06:54:51 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbzC-0001d8-KT; Tue, 20 Mar 2007 06:54:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbzA-0001d1-KD for 6lowpan@ietf.org; Tue, 20 Mar 2007 06:54:36 -0400 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbzA-0007aK-7Y for 6lowpan@ietf.org; Tue, 20 Mar 2007 06:54:36 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l2KAsXtj011283; Tue, 20 Mar 2007 11:54:34 +0100 (CET) In-Reply-To: <200703201050.l2KAoDFL008281@moth.iki.fi> References: <733445.22863.qm@web81903.mail.mud.yahoo.com> <200703201042.l2KAgWWD008107@moth.iki.fi> <200703201050.l2KAoDFL008281@moth.iki.fi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4BEA098F-655A-4E24-8421-CC283625E4A0@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [6lowpan] tentative rev 12 format draft: draft-ietf-6lowpan-format-12.txt Date: Tue, 20 Mar 2007 11:54:32 +0100 To: Markku Savela X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Carsten Bormann , 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 Mar 20 2007, at 11:50, Markku Savela wrote: > >> From: Markku Savela > >> Thus, this MTU (and resulting IPv6 packet size) is whatever the >> 6lowpan decides to specify. > > Occurs to me, as 6lowpan does it's own internal fragmentation anyway, > it could actually advertise very large MTU (like 4-16Kb) to avoid IPv6 > header overhead in bulk transfers. Well... > Whether sensible, depends how > likely the packet loss is on the link. Exactly, and with a very small L2 MTU and losses exacerbated by possible multi-hop L2 paths, you really want L4/L7 reliability for larger ADUs. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Mar 20 18:31:53 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTmrf-0000sZ-5d; Tue, 20 Mar 2007 18:31:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTmre-0000sU-Hp for 6lowpan@lists.ietf.org; Tue, 20 Mar 2007 18:31:34 -0400 Received: from email2.etri.re.kr ([129.254.16.132] helo=email2.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTmrd-00028m-4P for 6lowpan@lists.ietf.org; Tue, 20 Mar 2007 18:31:34 -0400 Received: from mail pickup service by email2.etri.info with Microsoft SMTPSVC; Wed, 21 Mar 2007 07:36:23 +0900 Priority: normal X-ReadCheckName: 6lowpan%40lists.ietf.org Thread-Topic: 6lowpan routing requirement presentation X-ReadCheckMessageID: thread-index: AcdrQC/9Lw3eCr9wRKa8g9JmtUHhhg== From: =?ks_c_5601-1987?B?tbW5zLTPxak=?= To: <6lowpan@lists.ietf.org> Bcc: Date: Wed, 21 Mar 2007 07:36:23 +0900 Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCDC97y8tOvAzsXNs90gx6XB2A==?= =?ks_c_5601-1987?B?v6yxuMbALCC047Tn?= Message-ID: <035501c76b40$2fffa2f0$8410fe81@etri.info> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Content-class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 X-OriginalArrivalTime: 20 Mar 2007 22:36:23.0274 (UTC) FILETIME=[301E9CA0:01C76B40] X-Spam-Score: 3.5 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [6lowpan] 6lowpan routing requirement presentation X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ks_c_5601-1987?B?tbW5zLTPxak=?= 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="===============0223982535==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0223982535== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----=_NextPart_000_0356_01C76B8B.9FE74AF0" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_0356_01C76B8B.9FE74AF0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 ------=_NextPart_000_0356_01C76B8B.9FE74AF0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy Ij4NCjxESVY+SGkgYWxsLDxCUj48QlI+UGxlYXNlIG5vdGUgdGhhdCB0aGUgc2xpZGVzIGZvciBt eSBwcmVzZW50YXRpb24gb24gNmxvd3BhbiByb3V0aW5nIHJlcXVpcmVtZW50cyBodmUgYmVlbiBt YWRlIGF2YWlsYWJsZS4gVW5mb3J0dW5hdGVseSBJIHdhcyBub3QgYWJsZSB0byBwcmVzZW50LCBk dWUgdG8gbGFjayBvZiB0aW1lLiBJdCB3b3VsZCBiZSBncmVhdCBpZiBpbnRlcmVzdGVkIHBlb3Bs ZSBjb3VsZCBoYXZlIGEgbG9vayBhbmQgZ2l2ZSBzb21lIGNvbW1lbnRzIGFuZCBmZWVkYmFjayBv biBpdDo8L0RJVj4NCjxESVY+Jm5ic3A7PEJSPmh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRp bmdzLzA3bWFyL3NsaWRlcy82bG93cGFuLTEucHB0PEJSPjxCUj5BbHNvLCBJIHdvdWxkIGxpa2Ug dG8gbWVudGlvbiB0aGF0IDZsb3dwYW4gcm91dGluZyB3aWxsIGJyaWVmbHkgYmUgZGlzY3Vzc2Vk IGluIHRoZSBNQU5FVCBzZXNzaW9uIG9uIFdlZG5lc2RheS4gUGxlYXNlIGNvbWUgYnkgYW5kIHNw ZWFrIHVwIHlvdXIgb3Bpbmlvbi48QlI+PEJSPlRoYW5rcywgPEJSPkRvbWluaWs8QlI+PEJSPjwv RElWPjwvRElWPjxpbWcgc3R5bGU9ImRpc3BsYXk6bm9uZSIgd2lkdGg9MCBoZWlnaHQ9MCBzcmM9 Imh0dHA6Ly91bWFpbC5ldHJpLnJlLmtyL0V4dGVybmFsX1JlYWRDaGVjay5hc3B4P2VtYWlsPTZs b3dwYW5AbGlzdHMuaWV0Zi5vcmcmbmFtZT02bG93cGFuJTQwbGlzdHMuaWV0Zi5vcmcmZnJvbWVt YWlsPWRvbWluaWtAZXRyaS5yZS5rciZtZXNzYWdlaWQ9JTNDZDQwYzZhYzktYTJlNy00ZDVmLTk0 YTItZDRjZTJmNWNmNzhjQGV0cmkucmUua3IlM0UiPg== ------=_NextPart_000_0356_01C76B8B.9FE74AF0-- --===============0223982535== 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 --===============0223982535==-- From 6lowpan-bounces@ietf.org Tue Mar 20 19:49:41 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTo52-0000At-MX; Tue, 20 Mar 2007 19:49:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTo50-000094-VB for 6lowpan@ietf.org; Tue, 20 Mar 2007 19:49:27 -0400 Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTo4x-0004ru-6K for 6lowpan@ietf.org; Tue, 20 Mar 2007 19:49:26 -0400 Received: from mail.dei.uc.pt (mail.dei.uc.pt [193.136.212.3]) by smtp2.dei.uc.pt (8.13.8/8.13.8) with ESMTP id l2KNmKCq001492; Tue, 20 Mar 2007 23:48:20 GMT Received: from mail.dei.uc.pt (localhost [127.0.0.1]) by mail.dei.uc.pt (8.13.6/8.13.6) with ESMTP id l2KNmFGI029942; Tue, 20 Mar 2007 23:48:15 GMT Received: (from daemon@localhost) by mail.dei.uc.pt (8.13.6/8.13.5/Submit) id l2KNmAQ4029941; Tue, 20 Mar 2007 23:48:10 GMT Received: from r5j245.net.upc.cz (r5j245.net.upc.cz [86.49.9.245]) by mail.dei.uc.pt (Horde MIME library) with HTTP; Tue, 20 Mar 2007 23:48:10 +0000 Message-ID: <20070320234810.5gs73jven4kg8wcc@mail.dei.uc.pt> Date: Tue, 20 Mar 2007 23:48:10 +0000 From: Tiago Camilo To: Samita Chakrabarti Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> <024b01c76470$1e3b8380$8770fe81@etri964caf1384> <008201c76763$250bc4e0$8770fe81@etri964caf1384> <45FA8936.6080801@dei.uc.pt> <43b91d370703190036o478015c9v852a5e52c5fa18b2@mail.gmail.com> In-Reply-To: <43b91d370703190036o478015c9v852a5e52c5fa18b2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-WebMail-Company: University of Coimbra, Portugal, DEI X-Originating-IP: 86.49.9.245 X-Remote-Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-0.04, required 3, autolearn=not spam, AWL -0.04, SPF_HELO_PASS -0.00) X-FCTUC-DEI-SIC-MailScanner-From: tandre@dei.uc.pt X-Spam-Status: No X-Spam-Score: 1.8 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Samita, please see in-line comments, Quoting Samita Chakrabarti : > Hi Dominik and Tiago, > > Sorry for the delay in replying. Some additional comments are in-line. > >> > >> > In my opinion, RFD nodes should not have to detect their own movement. >> > Their movement should *be detected* by more capable devices... what do >> > you think? >> > >> I agree with this approach, it is important to reduce the network >> activity of the RFD nodes. One possible solution of such *detect* >> mechanism can be incorporated as one "LowPan Neighbor Discovery >> Extension", in the Chakrabarti ID. >> Tiago Camilo >> > > > Can you provide an example as to how the network or FFDs will detect new > nodes, that is more efficient than the RFDs doing it ? > If there is a 802.15.4 level presence detection, then the FFDs can > trigger some > messages to the new RFD for identification and address assignment. > But, it then > does not know if the RFD is in sleep mode or in awake mode. Thus, > FFDs will need > to send periodic messages in the network - the RFDs need to respond > anyway and > identify themselves. So, I don't see any advantages in network > initiated detection. I think Dominik was talking about procedures such as Binding Updates, Do you think RFD should send throughout their closest FFD periodical BUs? or should be the FFD the one responsible for informing the Home Router (Home PAN co-ordinator) about the new RFD CoA ? I prefer the last approach, due to the RFD energy limitations . > On the other hand, if the RFD moves to a new 6lowpan network, it > should associate > with the new FFD at the L2 layer (association/dissociation is part of > 802.15.4 spec). > Once it associates with a new FFD, the FFD then can send them cached > information on RA and prefix on the network ( this is not part of ND > draft yet, but > we can add it). Nevertheless,by choosing the second approach (FFD sending the BU), we need to warn somehow the FFD on the home address and the PAN co-ordinator address of the RFD, maybe after receiving the RA. -- Tiago Camilo PhD student Laboratory of Communication and Telematics University of Coimbra > But, I agree with you folks that we should specifically talk about RFD > function in the requirement document. > > Thanks, > -Samita > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Mar 21 04:38:51 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwKy-0000yG-Tb; Wed, 21 Mar 2007 04:38:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwKx-0000xj-0s for 6lowpan@ietf.org; Wed, 21 Mar 2007 04:38:27 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTwKn-0004dm-Of for 6lowpan@ietf.org; Wed, 21 Mar 2007 04:38:25 -0400 Received: by py-out-1112.google.com with SMTP id f47so60940pye for <6lowpan@ietf.org>; Wed, 21 Mar 2007 01:38:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=j1QPlGp8wxQAWFgGZG27qOumIJ1DF1Vi/TSU8Lm18hzDkK2B9HqSeqSiXm78ZSdRfg8MtQtd25VrBbRp0aNWz2+tKTaFAAvz4AioVVWSObZOp34oaLmbexGkOcmKFjSEijBRvrekztmBKrxwudwh0yjtX5vc+tHRBcisUKwmJUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=MpUGMGdpyCnpxE/rKD4Vx8tUBvSVGPWMXtsx9KwnyLyxui/ukNprlzaZ68QnXrHQd1hUahgYeA9bg+Q9v6I2nUKsFsFdXiV1heKyF1Prz8SZUtMXYJuJYGAW/8KWQSQqM6oPlNcT0TJ3tUXCTLguwNKSFZ4GlkapO0+g1o8QjT4= Received: by 10.35.121.2 with SMTP id y2mr975337pym.1174466291264; Wed, 21 Mar 2007 01:38:11 -0700 (PDT) Received: from ?130.129.22.124? ( [130.129.22.124]) by mx.google.com with ESMTP id w38sm3432246pyg.2007.03.21.01.38.07; Wed, 21 Mar 2007 01:38:09 -0700 (PDT) Message-ID: <4600EEEC.40108@gmail.com> Date: Wed, 21 Mar 2007 17:38:04 +0900 From: Myung-Ki Shin Organization: ETRI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tiago Camilo Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> <024b01c76470$1e3b8380$8770fe81@etri964caf1384> <008201c76763$250bc4e0$8770fe81@etri964caf1384> <45FA8936.6080801@dei.uc.pt> <43b91d370703190036o478015c9v852a5e52c5fa18b2@mail.gmail.com> <20070320234810.5gs73jven4kg8wcc@mail.dei.uc.pt> In-Reply-To: <20070320234810.5gs73jven4kg8wcc@mail.dei.uc.pt> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: myungki.shin@gmail.com 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 agree with Tiago. I think mobility support might be also dependent on architecture and scenarios of 6lowpan deployment, but in general, I also prefer signalling (e.g., BU) in mobile RFD nodes shoud be avoided or reducing signalling should be severely considered due to the RFD energy limitations. Instead, I favor "FFD sending the (proxy) BU" like PMIPv6. In addition, we shoud consider MANEMO scenario and its solution for movement of 6lowpan networks. At this time, I'm writing up a solution document for mobility support and optimization for 6lowpan applications based on Samita's requirement document (the requirements seem to be not clear with me yet, though) I think we can work together on this topic. Regards, Myung-Ki, Tiago Camilo wrote: > Hi Samita, > please see in-line comments, > > Quoting Samita Chakrabarti : > >> Hi Dominik and Tiago, >> >> Sorry for the delay in replying. Some additional comments are in-line. >> >>> > >>> > In my opinion, RFD nodes should not have to detect their own movement. >>> > Their movement should *be detected* by more capable devices... what do >>> > you think? >>> > >>> I agree with this approach, it is important to reduce the network >>> activity of the RFD nodes. One possible solution of such *detect* >>> mechanism can be incorporated as one "LowPan Neighbor Discovery >>> Extension", in the Chakrabarti ID. >>> Tiago Camilo >>> >> >> >> Can you provide an example as to how the network or FFDs will detect new >> nodes, that is more efficient than the RFDs doing it ? >> If there is a 802.15.4 level presence detection, then the FFDs can >> trigger some >> messages to the new RFD for identification and address assignment. >> But, it then >> does not know if the RFD is in sleep mode or in awake mode. Thus, FFDs >> will need >> to send periodic messages in the network - the RFDs need to respond >> anyway and >> identify themselves. So, I don't see any advantages in network >> initiated detection. > > > I think Dominik was talking about procedures such as Binding Updates, > Do you think RFD should send throughout their closest FFD periodical BUs? > or should be the FFD the one responsible for informing the Home Router > (Home PAN co-ordinator) about the new RFD CoA ? > I prefer the last approach, due to the RFD energy limitations . > >> On the other hand, if the RFD moves to a new 6lowpan network, it >> should associate >> with the new FFD at the L2 layer (association/dissociation is part of >> 802.15.4 spec). >> Once it associates with a new FFD, the FFD then can send them cached >> information on RA and prefix on the network ( this is not part of ND >> draft yet, but >> we can add it). > > > Nevertheless,by choosing the second approach (FFD sending the BU), we > need to warn somehow the FFD on the home address and the PAN co-ordinator > address of the RFD, maybe after receiving the RA. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Mar 21 10:50:18 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU28c-00045n-Dn; Wed, 21 Mar 2007 10:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU28Y-00044e-Q0 for 6lowpan@lists.ietf.org; Wed, 21 Mar 2007 10:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU28Y-0005S7-BJ for 6lowpan@lists.ietf.org; Wed, 21 Mar 2007 10:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 4EF3C32899; Wed, 21 Mar 2007 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HU28Y-0007Wm-7M; Wed, 21 Mar 2007 10: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: Wed, 21 Mar 2007 10:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: 6lowpan@lists.ietf.org Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-format-12.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low power WPAN Working Group of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.15.4 Networks Author(s) : G. Montenegro, et al. Filename : draft-ietf-6lowpan-format-12.txt Pages : 31 Date : 2007-3-21 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-12.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-12.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-12.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: <2007-3-21060556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-6lowpan-format-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-6lowpan-format-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-21060556.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --NextPart-- From 6lowpan-bounces@ietf.org Wed Mar 21 16:33:51 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU7V4-0005CO-UB; Wed, 21 Mar 2007 16:33:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU7V3-0005CI-HS for 6lowpan@ietf.org; Wed, 21 Mar 2007 16:33:37 -0400 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU7Um-00077l-Qp for 6lowpan@ietf.org; Wed, 21 Mar 2007 16:33:37 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l2LKXJIU021233; Wed, 21 Mar 2007 21:33:19 +0100 (CET) In-Reply-To: <008201c76763$250bc4e0$8770fe81@etri964caf1384> References: <43b91d370703111608r6bb11969y2de6577408a9df52@mail.gmail.com> <024b01c76470$1e3b8380$8770fe81@etri964caf1384> <008201c76763$250bc4e0$8770fe81@etri964caf1384> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2138B298-1CD3-41FC-8A1B-EEBFB198284B@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated Date: Wed, 21 Mar 2007 21:33:17 +0100 To: 6lowpan@ietf.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Carsten Bormann X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Mar 16 2007, at 01:36, Dominik Kaspar wrote: > RFD nodes should not have to detect their own movement. Their > movement should *be detected* by more capable devices RFD nodes, if relying on that, don't want to fall into the hands of the "more capable devices" of the adversary. So they at least may have to be able to find out whether they are still (or newly) connected to a friendly FFD or in one of the two (not necessarily distinguishable) states "isolated" or "surrounded by adversaries only". We probably need the scenarios fleshed out with some more details before we can see which role(s) calls for RFDs and in which way these particular roles are "mobile" with respect to their FFD friends. On Mar 19 2007, at 09:22, Samita Chakrabarti wrote: > Currently our architecture ( as discussed in the > wg so far) is > hierarchical with bunch FFDs and RFDs hanging off of FFDs and there > is one > IPv6 router at the top ( please see the 6lowpan-ipv6-nd draft for that > assumption). (Putting WG chair hat on:) This is correct. We just have to be careful not to refer to this mental model as "the 6lowpan architecture", as we the WG haven't agreed on one yet. (Hat off again:) I personally think this structure would be good as one, but not necessarily the only structure supported by the 6lowpan protocols. But we aren't there yet: As we said during the meeting, we need to understand a reasonable set of 6lowpan scenarios and the (qualitative and quantitative) workloads generated by them. And then we need to work on those we want to support, together with the structural models ("architectures") that will be used to support them. So, if you want to continue this discussion, please be concrete (as in "I have this airport with several 100 m of hallways that have RFD temp sensors that are each within 8 m of FFD light controllers spaced 12 m apart and a maintenance guy with a set of mutually connected FFD maintenance devices roaming in these hallways"). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan