From mdurvy@cisco.com Wed May 5 07:28:05 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E243A68C4; Wed, 5 May 2010 07:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.989 X-Spam-Level: X-Spam-Status: No, score=-8.989 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8Ybe0APlfbY; Wed, 5 May 2010 07:28:04 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B62923A6C0E; Wed, 5 May 2010 07:19:11 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4235 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKsb4UurR7Ht/2dsb2JhbACdRnGkNJlVhRME X-IronPort-AV: E=Sophos;i="4.52,333,1270425600"; d="p7s'?scan'208";a="323260321" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 05 May 2010 14:18:58 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o45EItPT003953; Wed, 5 May 2010 14:18:58 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 May 2010 16:18:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 May 2010 16:18:49 +0200 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_00A9_01CAEC6E.A4D85880"; protocol="application/x-pkcs7-signature" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] how does a node get an IP address Thread-Index: AcrmpoOjTf0fKczJRTyzv8B1l61fYgAwZgEAATywzKA= References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , , "Richard Kelsey" X-OriginalArrivalTime: 05 May 2010 14:18:52.0201 (UTC) FILETIME=[E33CD990:01CAEC5D] Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 05 May 2010 14:28:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01CAEC6E.A4D85880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pascal, I fully agree with you. In my opinion anything spanning multiple IP hops should not be done by ND. On a related topic.... 6lowpan network have the particularity that you cannot use on-link prefix due to the non-transitivity of the wireless links. This means we need to tell routers how to reach neighboring IPv6 hosts. So essentially 6lowpan-ND is using a registration mechanism to establish a "route" between the router and the host. It is not clear to me whether this is the role of ND or of the routing protocol. I think it could actually be both. Hence the questions: - Are IPv6 hosts possible in a 6lowpan network where the RPL protocol is used? - Should IPv6 hosts be part of a RPL topology (as leaf node) or should IPv6 hosts use the 6lowpan-ND host-router spec? Best, Mathilde -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: jeudi, 29. avril 2010 09:01 To: zach.shelby@sensinode.com; Richard Kelsey Cc: roll@ietf.org; 6lowpan@ietf.org Subject: Re: [Roll] how does a node get an IP address Hi Zach: I have yet to review the new ND-09 but my guts tell me that it is the wrong place to do the job. Router to router is usually routing protocol land and ND is definitely not a routing protocol. The main question is how long can a router advertise a prefix, and the answer is, as long as it is in the same subnet of an authoritative router that owns the prefix. Asserting the continuous reachability of the authoritative router is a routing protocol problem. Maintaining a subnet together is the job for a new form of Gateway Protocol, a Subnet Gateway Protocol RPL is just that. Let see: - Propagating the RA content is not an ND intrinsic problem, it only comes with route over. And route over comes with a routing protocol. - the route over protocol should be able to tie the route over subnetwork together so it is a SGP. So why can't we just say in 6LoWPAN ND that you for those who use it in route over we expect an SGP to tie the route over subnetwork together and that the SGP should transport the RA content, maintaining the validity with the reachability of the authoritative router? I can write that text if you wish. It seems that we have a reasonable consensus in this thread to do exactly that in RPL anyway... Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > zach.shelby@sensinode.com > Sent: Tuesday, April 27, 2010 10:36 PM > To: Richard Kelsey > Cc: roll@ietf.org > Subject: Re: [Roll] how does a node get an IP address > > Hi Everyone, > > Let me jump into this thread - just to make things more interesting ;-) First, I > recommend everyone goes and reads 6lowpan-nd-09 which was submitted > today. When it comes to ND, you need to separate two interfaces. > > 1. The host-router interface > > Hosts know absolutely nothing about RPL (nor should they). Thus in this case > ND* does the job, and RS/RA is used for obtaining a prefix and initializing its > addresses. I think some people in the thread are referring to this. > > 2. The router-router interface > > As in RFC4861, in 6lowpan-nd-09 routers have more flexibility than hosts in > how they obtain prefix information (among other things). nd-09 does include > an optional technique for an authorative border router to disseminate PIOs > and CIOs (Context Information Options) between the border router and all > routers in the LoWPAN using RAs. It is actually a decent mechanism and > improved over early versions. The draft clearly states that it is optional as a > routing algorithm may already do this. So Pascal is correct in that respect. I > haven't followed the thread well enough to have an opinion if RPL should do > that. > > Routers will also find other features of 6lowpan-nd-09 useful, for example > during initial bootstrapping, to maintain their default router and neighbor > caches, avoid the need for address resolution, and to perform NUD. The > draft (tries to) clearly state when features are required or optional for a > router. > > Zach > > > >> From: Michael Richardson > >> Date: Tue, 27 Apr 2010 10:38:47 -0400 > >> > >> >>>>> "Richard" == Richard Kelsey writes: > >> >> Date: Tue, 27 Apr 2010 14:18:32 +0200 From: "Pascal Thubert > >> >> (pthubert)" > >> >> > >> >> The question here is that the authoritative routers need to > >> >> disseminate the PIO (and the RIO) to all routers in the subnet. > >> > >> Richard> How do other routing protocols (OSPF, IS-IS, AODV, OLSR) > >> > >> I can only speak for OSPF and ISIS. > >> Neither deal with multi-hop subnets or with any kind of address > >> assignment. > > > > Why should RPL be any different? Yes, it will be run on multi-hop > > subnets, but I still do not see how this affects the routing. > > > >> Both were written when multicast was very new. > > > > I am not sure how RPL's handling of multicast matters here. > > While RPL is required to route multi-hop multicasts, ND uses > > link-local multicasts, which do not require routing. > > > >> Richard> I understand that multi-hop subnets are a problem for ND, > >> Richard> but I don't see how the routing protocol is affected. > >> > >> RPL either requires 6lowpan, or it doesn't. > > > > RPL should work fine with ordinary ND. Why would it require 6lowpan? > > > >> If it doesn't, then it has to provide for ND to work, or for another > >> protocol to replace it. > > > > ND works fine, using link-local, one-hop multicasts. RPL need not be > > involved. > > > > If someone wants to run RPL on a node that uses neither ordinary ND or > > 6lowpan's version, then they will need some third variety of ND. I do > > not see why this is an issue for RPL to address. It seems quite out > > of scope. > > > > -Richard Kelsey > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_00A9_01CAEC6E.A4D85880 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2jCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTFMIIDraADAgECAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkxMTI2MDAw MDAwWhcNMTAxMTI2MjM1OTU5WjCCARIxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG dWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1hdGhpbGRlIER1cnZ5MR8wHQYJKoZIhvcNAQkBFhBtZHVy dnlAY2lzY28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR9oVSAz6Tlt7xUvAb+IKp aqKdu1dh0cihpjNNzndIzit+ZWpixDZ8tWBtpZ7T2jBC+SiyquqIrin/TD4jlk60y4OBBeF2zlJa c6P0Ay8g4WjDRnvJP93Wz93W32bgjtV1R7FRlWUxPjn9QUDcq4PIHd4qFKSiOMfKk1OijYeWRQID AQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAU BggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRh bElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQA9I2FwWjWGMNapHvMFY2LZN+qr3cX6ILBUZ1AxypApr5B2Hl8YXDMA6o8Gtd5J2wxkJmEAbqXT zkoVWspigsclFSbGDu5V0ITLLZzzCXvwnpeaUD4F9GngqdkNUZkqXirqaMZxQTiaI5Hue2RX3f7b Ew4GqU+KMg6meor5iMoyGl/mtZ0LSPj6ZltNaG7ElQoyTXfdBGXlEm8z2uJhtb42Ys2OUptP1v3x jhxT2njv9NMcBH4q7S6y+op0aFrVsNLP7+qcPSBZlEcav3vyNSygxnqyx+pMJmgWH+/VdwsbSIDB FAo4DoI+fe2pUIeqRx6yP9s+e21BRiSPxvBtVe+JMIIEzDCCBDWgAwIBAgIQHK6da5r05i8iiqPa dGFsHjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkwHhcNMDUxMDI4MDAwMDAwWhcNMTUxMDI3MjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAyd+s5+r4+AMUxACS1cF+NsI873xyFcvAq4w9HJXObx4QLD8A7Zcm5rbH5q1DHT+kh0dH TD5U+Gz4x/yxnr0wcLyXsQMF6pXxrUDFRHpLBaLyYPzXOmVi7/8Qe6JWu8VOcC3Woh887bBC6F6N VyGsppnZEenSGgfAdEdCC/zFNOr95rok0R0IFTei13PPAUEvY7I6P76lGm70yUpbPZWmFbs1Ahn5 1O+8jw5xdlm7S7Y+1vxaFvTWDonySf5sDO0V6dmIdZx5zmAn3bmtdc4vc5V6QDqFdUmwuN9ovKvN E4KFEVCj4DwLrsAKU83XMG+FMkYb5EkQwmzirx95/9u0tQIDAQABo4IBhDCCAYAwEgYDVR0TAQH/ BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQU EX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2ln bi5jb20vcGNhMS5jcmwwgYEGA1UdIwR6MHihY6RhMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eYIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQEFBQADgYEAsS/ZluGS ou6BYOXIKiD74Wcs1gCYU6MCG+mQS/gYRJ8PRvf6oP7THRij0r8c7NYZn0pNQ/jKu74TgEkF3SFz M1fCQlq++gCTsuYEMZFOXTzwcwU3Y+u/g1mY/Wbe6YYympIpPDquVNqmElGxj8jK00d45tulHocG 49EUwMIh9roxggRzMIIEbwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDUwNTE0MTg0OFowIwYJKoZI hvcNAQkEMRYEFA0Cpfu10ynHDynMvfSuVyZ56/w1MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAfeqJ ems16P/qPTvuidKUxZY/dC0+1+H1ZLhmIuh5S81Yy+fGe2/fm7yoMghg7x9zigAvw/7727zPwon7 t3kDA1WKkqsFY0ueq6IUF0wpk7zHeKUKgZlrAKkRntLrNl7F++F9e0d1IpRca2tsvQ9Me71pVZH9 +LTXzjf6vJFct5YAAAAAAAA= ------=_NextPart_000_00A9_01CAEC6E.A4D85880-- From zach@sensinode.com Wed May 5 08:49:47 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10693A6C5A; Wed, 5 May 2010 08:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.019 X-Spam-Level: X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wRiilXbCwDO; Wed, 5 May 2010 08:49:45 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 349A23A6C19; Wed, 5 May 2010 08:42:38 -0700 (PDT) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o45FgCNs011538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 May 2010 18:42:13 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> Date: Wed, 5 May 2010 18:42:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> To: Mathilde Durvy (mdurvy) X-Mailer: Apple Mail (2.1077) Cc: zach.shelby@sensinode.com, roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 05 May 2010 15:49:47 -0000 Hi, On May 5, 2010, at 17:18 , Mathilde Durvy (mdurvy) wrote: > Hi Pascal, >=20 > I fully agree with you. > In my opinion anything spanning multiple IP hops should not be done by = ND. That logic doesn't work anymore with route-over LoWPANs. As the prefixes = are spanning the whole LoWPAN there is a natural need for ND to help = with that. In the case of RPL, the WG may decide to disseminate some = things such as prefix information between routers in a LoWPAN using the = routing protocol. 6lowpan-nd-09 states clearly that you may do that, so = nothing stopping RPL there. What is this argument about? You are = complaining about something that is not a problem?=20 Now RPL isn't the only routing protocol.... 6lowpan-nd-09 provides an = optional mechanism of using RS/RA for disseminating prefix and context = information between all routers in a LoWPAN that is routing protocol = independent. Regardless of RPL, this will surely come in handy and some = routing protocols may even specify to use this mechanism. =20 Let me remind you of how RPL started by the way. In the beginning the = idea was to piggyback RPL information on ND traffic as there were = already similar flows. Eventually the WG decided to give RPL its own = messages instead of piggybacking as ND options. Now it has gone to the = extreme of RPL being the one and only protocol and everything must be = carried on that.... Quite a change! Next we could piggyback DHCPv6 on = RPL, use RPL for DAD, and what the heck, let's go for DNS too... Starts = to sound like a shopping-TV ad for a super-vegetable-processing-miracle = doesn't it?=20 >=20 > On a related topic.... > 6lowpan network have the particularity that you cannot use on-link = prefix > due to the non-transitivity of the wireless links. This means we need = to > tell routers how to reach neighboring IPv6 hosts. So essentially = 6lowpan-ND > is using a registration mechanism to establish a "route" between the = router > and the host. =20 It is actually letting the host and router know about each other (router = discovery), their reachability (NUD) and their L2 addresses (address = resolution). These are all standard features of ND. > It is not clear to me whether this is the role of ND or of the routing > protocol. I think it could actually be both.=20 > Hence the questions:=20 > - Are IPv6 hosts possible in a 6lowpan network where the RPL protocol = is > used? Better be, or you just broke an important model of IPv6. I would say it = MUST be possible for hosts to attach to a LoWPAN running RPL (and stay = blissfully ignorant of RPL).=20 > - Should IPv6 hosts be part of a RPL topology (as leaf node) or should = IPv6 > hosts use the 6lowpan-ND host-router spec? ND is clearly the standard host-router interface regardless of IPv6 or = 6LoWPAN. Forcing hosts to know anything about RPL would be insane...=20 Zach >=20 > Best, > Mathilde=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > Pascal Thubert (pthubert) > Sent: jeudi, 29. avril 2010 09:01 > To: zach.shelby@sensinode.com; Richard Kelsey > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: Re: [Roll] how does a node get an IP address >=20 > Hi Zach: >=20 > I have yet to review the new ND-09 but my guts tell me that it is the = wrong > place to do the job. Router to router is usually routing protocol land = and > ND is definitely not a routing protocol. >=20 > The main question is how long can a router advertise a prefix, and = the > answer is, as long as it is in the same subnet of an authoritative = router > that owns the prefix. > Asserting the continuous reachability of the authoritative router is a > routing protocol problem. Maintaining a subnet together is the job for = a new > form of Gateway Protocol, a Subnet Gateway Protocol RPL is just that. >=20 > Let see: >=20 > - Propagating the RA content is not an ND intrinsic problem, it only = comes > with route over. And route over comes with a routing protocol. > - the route over protocol should be able to tie the route over = subnetwork > together so it is a SGP. >=20 > So why can't we just say in 6LoWPAN ND that you for those who use it = in > route over we expect an SGP to tie the route over subnetwork together = and > that the SGP should transport the RA content, maintaining the validity = with > the reachability of the authoritative router? I can write that text if = you > wish. >=20 > It seems that we have a reasonable consensus in this thread to do = exactly > that in RPL anyway... >=20 > Pascal >=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> zach.shelby@sensinode.com >> Sent: Tuesday, April 27, 2010 10:36 PM >> To: Richard Kelsey >> Cc: roll@ietf.org >> Subject: Re: [Roll] how does a node get an IP address >>=20 >> Hi Everyone, >>=20 >> Let me jump into this thread - just to make things more interesting > ;-) First, I >> recommend everyone goes and reads 6lowpan-nd-09 which was submitted=20= >> today. When it comes to ND, you need to separate two interfaces. >>=20 >> 1. The host-router interface >>=20 >> Hosts know absolutely nothing about RPL (nor should they). Thus in > this case >> ND* does the job, and RS/RA is used for obtaining a prefix and > initializing its >> addresses. I think some people in the thread are referring to this. >>=20 >> 2. The router-router interface >>=20 >> As in RFC4861, in 6lowpan-nd-09 routers have more flexibility than > hosts in >> how they obtain prefix information (among other things). nd-09 does > include >> an optional technique for an authorative border router to disseminate > PIOs >> and CIOs (Context Information Options) between the border router and > all >> routers in the LoWPAN using RAs. It is actually a decent mechanism = and=20 >> improved over early versions. The draft clearly states that it is > optional as a >> routing algorithm may already do this. So Pascal is correct in that > respect. I >> haven't followed the thread well enough to have an opinion if RPL > should do >> that. >>=20 >> Routers will also find other features of 6lowpan-nd-09 useful, for > example >> during initial bootstrapping, to maintain their default router and > neighbor >> caches, avoid the need for address resolution, and to perform NUD. = The=20 >> draft (tries to) clearly state when features are required or optional > for a >> router. >>=20 >> Zach >>=20 >>=20 >>>> From: Michael Richardson >>>> Date: Tue, 27 Apr 2010 10:38:47 -0400 >>>>=20 >>>>>>>>> "Richard" =3D=3D Richard Kelsey > writes: >>>>>> Date: Tue, 27 Apr 2010 14:18:32 +0200 From: "Pascal Thubert >>>>>> (pthubert)" >>>>>>=20 >>>>>> The question here is that the authoritative routers need to >>>>>> disseminate the PIO (and the RIO) to all routers in the > subnet. >>>>=20 >>>> Richard> How do other routing protocols (OSPF, IS-IS, AODV, > OLSR) >>>>=20 >>>> I can only speak for OSPF and ISIS. >>>> Neither deal with multi-hop subnets or with any kind of address=20 >>>> assignment. >>>=20 >>> Why should RPL be any different? Yes, it will be run on multi-hop=20= >>> subnets, but I still do not see how this affects the routing. >>>=20 >>>> Both were written when multicast was very new. >>>=20 >>> I am not sure how RPL's handling of multicast matters here. >>> While RPL is required to route multi-hop multicasts, ND uses=20 >>> link-local multicasts, which do not require routing. >>>=20 >>>> Richard> I understand that multi-hop subnets are a problem for ND,=20= >>>> Richard> but I don't see how the routing protocol is affected. >>>>=20 >>>> RPL either requires 6lowpan, or it doesn't. >>>=20 >>> RPL should work fine with ordinary ND. Why would it require > 6lowpan? >>>=20 >>>> If it doesn't, then it has to provide for ND to work, or for > another >>>> protocol to replace it. >>>=20 >>> ND works fine, using link-local, one-hop multicasts. RPL need not > be >>> involved. >>>=20 >>> If someone wants to run RPL on a node that uses neither ordinary ND > or >>> 6lowpan's version, then they will need some third variety of ND. I > do >>> not see why this is an issue for RPL to address. It seems quite out=20= >>> of scope. >>>=20 >>> -Richard Kelsey=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>>=20 >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Head of Research, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Wed May 5 08:52:04 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A43028C0EE; Wed, 5 May 2010 08:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.678 X-Spam-Level: X-Spam-Status: No, score=-4.678 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ni0JDgzg01mR; Wed, 5 May 2010 08:52:03 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id C35553A6D2C; Wed, 5 May 2010 08:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o45FiUD7020355; Wed, 5 May 2010 17:44:30 +0200 (CEST) Received: from [192.168.217.101] (p5489EDE9.dip.t-dialin.net [84.137.237.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id ECEF6D092; Wed, 5 May 2010 17:44:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> Date: Wed, 5 May 2010 17:44:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> To: "Mathilde Durvy (mdurvy)" X-Mailer: Apple Mail (2.1078) Cc: zach.shelby@sensinode.com, roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 05 May 2010 15:52:04 -0000 > On a related topic.... > 6lowpan network have the particularity that you cannot use on-link = prefix > due to the non-transitivity of the wireless links. This means we need = to > tell routers how to reach neighboring IPv6 hosts. So essentially = 6lowpan-ND > is using a registration mechanism to establish a "route" between the = router > and the host. =20 > It is not clear to me whether this is the role of ND The role of ND here is doing the host-router neighbor discovery. > or of the routing > protocol. The role of RPL here is to disseminate the host route on towards other = routers. > I think it could actually be both. Hosts should not need to speak routing protocols. > Hence the questions:=20 > - Are IPv6 hosts possible in a 6lowpan network where the RPL protocol = is > used? I would consider it a major failure if RPL didn't support networks with = hosts. (Networks without hosts, i.e., all-router networks, are certainly = possible, but in a constrained node/network we are talking about a = relatively high lower bound on the complexity of nodes or a *very* = simple routing protocol. Of course, the routing protocol could distinguish three instead of two = complexity classes of nodes, supporting something like a "stub router" = [a router that cannot forward]. Still, that class would need to = implement some parts of the routing protocol, imposing constraints = either way or both.) > - Should IPv6 hosts be part of a RPL topology (as leaf node) or should = IPv6 > hosts use the 6lowpan-ND host-router spec? As I said, hosts shouldn't need to speak RPL. Gruesse, Carsten From behcetsarikaya@yahoo.com Wed May 5 09:23:47 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 131293A6C3F for <6lowpan@core3.amsl.com>; Wed, 5 May 2010 09:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-2R1Nim1ZLX for <6lowpan@core3.amsl.com>; Wed, 5 May 2010 09:23:47 -0700 (PDT) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id 9B04328C10F for <6lowpan@ietf.org>; Wed, 5 May 2010 09:19:53 -0700 (PDT) Received: (qmail 73830 invoked by uid 60001); 5 May 2010 16:19:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1273076377; bh=5OWHPifijNfl3SyMinm01j5VIg3VjSvlFvQGEl+oXPg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RpTHjq5OxNucTlu0oM95jp5JA/DvXRRD4Y+bRWeYNoB8PU6ypggSMYUC/Xd6/wOPTnvrvY3FIgPAV71Nw6WJV7WhnDxcmKIsBlMxYVf2aoSra3uWro0MPNWHh2064mWgCatDymWSjARU7tJjENridrvpecDd/2T7lakoumAa3Fg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=186twO+6ukxjrQwNV3ccxqUJFru3GHSQeNrRd6qDCN899jw5SlQcP7H+5lU2iC3s+NhGeEnNRUR48lIppWZelh1LMYN+wGhyKxeoKU7a6GW8JMqPA6X822NPC5NJ1YzCNPfaeoUUeeqH5WzMiDzZtF4CjoSxP/X3+gJ1QG/62y4=; Message-ID: <854597.72028.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: n.kP8mEVM1maBWQVHAf.rnXLOJiIlwJjPwgoTirmkMD393z PiZOWjbLz7.mbvbFPimoQU3tFdRjEtq2pft5Vo2ArH._jPpEzYzrh.LhA91y 6s7u9Sgz3zUXB52K6nKxauDfPo.lMZj8TnXZmAiNNbb7_2O_CdcW7br1b_dg 4Ktpbe1xo.RRsgrEAWJRYkk28NYsYFAfNDK06vaCgYORFsVZF8gWMHwuYeec o3tzEZyRZ8MYmyKSiTPf5hADpZuVsHrIhnghiicpqKL1mvWCG147Gp0235Hw mcwtm_ic.gKyuHsebqWivOrPFeTh2FWtNYOEP5g9JoNiUHzokzHNUpDFzZPa p9eHklrkdC5Qo Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Wed, 05 May 2010 09:19:37 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.103.269680 References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> Date: Wed, 5 May 2010 09:19:37 -0700 (PDT) From: Behcet Sarikaya To: Zach Shelby , Mathilde Durvy In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org, zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 16:23:47 -0000 I agree with Zach.=0AIP over foo has been taken up by IETF for all sorts of= "foo"s and 6lowpan ND is just doing that.=0A=0ARegards,=0A=0ABehcet=0A=0A= =0A=0A----- Original Message ----=0A> From: Zach Shelby =0A> To: Mathilde Durvy =0A> Cc: zach.shelby@sensinode.c= om; roll@ietf.org; 6lowpan@ietf.org=0A> Sent: Wed, May 5, 2010 10:42:14 AM= =0A> Subject: Re: [6lowpan] [Roll] how does a node get an IP address=0A> = =0A> Hi,=0A=0AOn May 5, 2010, at 17:18 , Mathilde Durvy (mdurvy) wrote:=0A= =0A> =0A> Hi Pascal,=0A> =0A> I fully agree with you.=0A> In my opinion =0A= > anything spanning multiple IP hops should not be done by ND.=0A=0AThat lo= gic =0A> doesn't work anymore with route-over LoWPANs. As the prefixes are = spanning the =0A> whole LoWPAN there is a natural need for ND to help with = that. In the case of =0A> RPL, the WG may decide to disseminate some things= such as prefix information =0A> between routers in a LoWPAN using the rout= ing protocol. 6lowpan-nd-09 states =0A> clearly that you may do that, so no= thing stopping RPL there. What is this =0A> argument about? You are complai= ning about something that is not a problem? =0A> =0A=0ANow RPL isn't the on= ly routing protocol.... 6lowpan-nd-09 provides an =0A> optional mechanism o= f using RS/RA for disseminating prefix and context =0A> information between= all routers in a LoWPAN that is routing protocol =0A> independent. Regardl= ess of RPL, this will surely come in handy and some routing =0A> protocols = may even specify to use this mechanism.=A0 =0A=0ALet me remind =0A> you of = how RPL started by the way. In the beginning the idea was to piggyback =0A>= RPL information on ND traffic as there were already similar flows. Eventua= lly =0A> the WG decided to give RPL its own messages instead of piggybackin= g as ND =0A> options. Now it has gone to the extreme of RPL being the one a= nd only protocol =0A> and everything must be carried on that.... Quite a ch= ange! Next we could =0A> piggyback DHCPv6 on RPL, use RPL for DAD, and what= the heck, let's go for DNS =0A> too... Starts to sound like a shopping-TV = ad for a =0A> super-vegetable-processing-miracle doesn't it? =0A=0A> =0A> O= n a =0A> related topic....=0A> 6lowpan network have the particularity that = you cannot =0A> use on-link prefix=0A> due to the non-transitivity of the w= ireless links. =0A> This means we need to=0A> tell routers how to reach nei= ghboring IPv6 hosts. =0A> So essentially 6lowpan-ND=0A> is using a registra= tion mechanism to establish =0A> a "route" between the router=0A> and the h= ost.=A0 =0A=0AIt is actually =0A> letting the host and router know about ea= ch other (router discovery), their =0A> reachability (NUD) and their L2 add= resses (address resolution). These are all =0A> standard features of ND.=0A= =0A> It is not clear to me whether this is the =0A> role of ND or of the ro= uting=0A> protocol. I think it could actually be =0A> both. =0A> Hence the = questions: =0A> - Are IPv6 hosts possible in a =0A> 6lowpan network where t= he RPL protocol is=0A> used?=0A=0ABetter be, or you =0A> just broke an impo= rtant model of IPv6. I would say it MUST be possible for hosts =0A> to atta= ch to a LoWPAN running RPL (and stay blissfully ignorant of RPL). =0A> =0A= =0A> - Should IPv6 hosts be part of a RPL topology (as leaf node) or =0A> s= hould IPv6=0A> hosts use the 6lowpan-ND host-router spec?=0A=0AND is =0A> c= learly the standard host-router interface regardless of IPv6 or 6LoWPAN. = =0A> Forcing hosts to know anything about RPL would be insane... =0A> =0A= =0AZach=0A=0A> =0A> Best,=0A> Mathilde =0A> =0A> =0A> -----Original Message= -----=0A> From: > ymailto=3D"mailto:roll-bounces@ietf.org" =0A> href=3D"mai= lto:roll-bounces@ietf.org">roll-bounces@ietf.org [mailto:> ymailto=3D"mailt= o:roll-bounces@ietf.org" =0A> href=3D"mailto:roll-bounces@ietf.org">roll-bo= unces@ietf.org] On Behalf =0A> Of=0A> Pascal Thubert (pthubert)=0A> Sent: j= eudi, 29. avril 2010 =0A> 09:01=0A> To: > href=3D"mailto:zach.shelby@sensin= ode.com">zach.shelby@sensinode.com; Richard =0A> Kelsey=0A> Cc: > href=3D"m= ailto:roll@ietf.org">roll@ietf.org; > ymailto=3D"mailto:6lowpan@ietf.org" = =0A> href=3D"mailto:6lowpan@ietf.org">6lowpan@ietf.org=0A> Subject: Re: [Ro= ll] =0A> how does a node get an IP address=0A> =0A> Hi Zach:=0A> =0A> I =0A= > have yet to review the new ND-09 but my guts tell me that it is the =0A> = wrong=0A> place to do the job. Router to router is usually routing protocol= =0A> land and=0A> ND is definitely not a routing protocol.=0A> =0A> The = =0A> main question is how long can=A0 a router advertise a prefix, and the= =0A> =0A> answer is, as long as it is in the same subnet of an authoritativ= e =0A> router=0A> that owns the prefix.=0A> Asserting the continuous =0A> r= eachability of the authoritative router is a=0A> routing protocol problem. = =0A> Maintaining a subnet together is the job for a new=0A> form of Gateway= =0A> Protocol, a Subnet Gateway Protocol RPL is just that.=0A> =0A> Let = =0A> see:=0A> =0A> - Propagating the RA content is not an ND intrinsic=A0 = =0A> problem, it only comes=0A> with route over. And route over comes with = a =0A> routing protocol.=0A> - the route over protocol should be able to ti= e the =0A> route over subnetwork=0A> together so it is a SGP.=0A> =0A> So w= hy =0A> can't we just say in 6LoWPAN ND that you for those who use it in=0A= > route =0A> over we expect an SGP to tie the route over subnetwork togethe= r and=0A> that =0A> the SGP should transport the RA content, maintaining th= e validity with=0A> =0A> the reachability of the authoritative router? I ca= n write that text if =0A> you=0A> wish.=0A> =0A> It seems that we have a re= asonable consensus =0A> in this thread to do exactly=0A> that in RPL anyway= ...=0A> =0A> =0A> Pascal=0A> =0A>> -----Original Message-----=0A>> From: > = ymailto=3D"mailto:roll-bounces@ietf.org" =0A> href=3D"mailto:roll-bounces@i= etf.org">roll-bounces@ietf.org [mailto:> ymailto=3D"mailto:roll-bounces@iet= f.org" =0A> href=3D"mailto:roll-bounces@ietf.org">roll-bounces@ietf.org] On= Behalf=0A> =0A> Of=0A>> > href=3D"mailto:zach.shelby@sensinode.com">zach.s= helby@sensinode.com=0A>> =0A> Sent: Tuesday, April 27, 2010 10:36 PM=0A>> T= o: Richard =0A> Kelsey=0A>> Cc: > href=3D"mailto:roll@ietf.org">roll@ietf.o= rg=0A>> Subject: Re: [Roll] =0A> how does a node get an IP address=0A>> =0A= >> Hi =0A> Everyone,=0A>> =0A>> Let me jump into this thread - just to make= =0A> things more interesting=0A> ;-) First, I=0A>> recommend everyone goes= =0A> and reads 6lowpan-nd-09 which was submitted =0A>> today. When it come= s to =0A> ND, you need to separate two interfaces.=0A>> =0A>> 1. The =0A> h= ost-router interface=0A>> =0A>> Hosts know absolutely nothing =0A> about RP= L (nor should they). Thus in=0A> this case=0A>> ND* does the =0A> job, and = RS/RA is used for obtaining a prefix and=0A> initializing =0A> its=0A>> add= resses. I think some people in the thread are referring to =0A> this.=0A>> = =0A>> 2. The router-router interface=0A>> =0A> =0A>> As in RFC4861, in 6low= pan-nd-09 routers have more flexibility =0A> than=0A> hosts in=0A>> how the= y obtain prefix information (among =0A> other things). nd-09 does=0A> inclu= de=0A>> an optional technique for =0A> an authorative border router to diss= eminate=0A> PIOs=0A>> and CIOs =0A> (Context Information Options) between t= he border router and=0A> =0A> all=0A>> routers in the LoWPAN using RAs. It = is actually a decent =0A> mechanism and =0A>> improved over early versions.= The draft clearly =0A> states that it is=0A> optional as a=0A>> routing al= gorithm may =0A> already do this. So Pascal is correct in that=0A> respect.= I=0A>> =0A> haven't followed the thread well enough to have an opinion if = RPL=0A> should =0A> do=0A>> that.=0A>> =0A>> Routers will also find other = =0A> features of 6lowpan-nd-09 useful, for=0A> example=0A>> during initial = =0A> bootstrapping, to maintain their default router and=0A> neighbor=0A>> = =0A> caches, avoid the need for address resolution, and to perform NUD. The= =0A> =0A>> draft (tries to) clearly state when features are required or = =0A> optional=0A> for a=0A>> router.=0A>> =0A>> =0A> Zach=0A>> =0A>> =0A>>>= > From: Michael Richardson =0A> <> href=3D"mailto:mcr@sandelman.ca">mcr@san= delman.ca>=0A>>>> =0A> Date: Tue, 27 Apr 2010 10:38:47 -0400=0A>>>> =0A> = =0A>>>>>>>>> "Richard" =3D=3D Richard Kelsey <> ymailto=3D"mailto:richard.k= elsey@ember.com" =0A> href=3D"mailto:richard.kelsey@ember.com">richard.kels= ey@ember.com>=0A> =0A> writes:=0A>>>>>> Date: Tue, 27 Apr 2010 14:18:32 +02= 00 From: =0A> "Pascal Thubert=0A>>>>>> (pthubert)" <> ymailto=3D"mailto:pth= ubert@cisco.com" =0A> href=3D"mailto:pthubert@cisco.com">pthubert@cisco.com= >=0A>>>>>> =0A> =0A>>>>>> The question here is that the authoritative route= rs =0A> need to=0A>>>>>> disseminate the PIO (and the RIO) to all =0A> rout= ers in the=0A> subnet.=0A>>>> =0A>>>>=A0 =0A> =A0 Richard> How do other rou= ting protocols (OSPF, IS-IS, AODV,=0A> =0A> OLSR)=0A>>>> =0A>>>> I can only= speak for OSPF and =0A> ISIS.=0A>>>> Neither deal with multi-hop subnets o= r with any kind =0A> of address =0A>>>> assignment.=0A>>> =0A>>> Why =0A> s= hould RPL be any different?=A0 Yes, it will be run on multi-hop =0A> =0A>>>= subnets, but I still do not see how this affects the =0A> routing.=0A>>> = =0A>>>> Both were written when multicast =0A> was very new.=0A>>> =0A>>> I = am not sure how RPL's handling =0A> of multicast matters here.=0A>>> While = RPL is required to route =0A> multi-hop multicasts, ND uses =0A>>> link-loc= al multicasts, which do =0A> not require routing.=0A>>> =0A>>>> Richard> I = =0A> understand that multi-hop subnets are a problem for ND, =0A>>>> =0A> R= ichard> but I don't see how the routing protocol is =0A> affected.=0A>>>> = =0A>>>> RPL either requires 6lowpan, =0A> or it doesn't.=0A>>> =0A>>> RPL s= hould work fine with =0A> ordinary ND.=A0 Why would it require=0A> 6lowpan?= =0A>>> =0A> =0A>>>> If it doesn't, then it has to provide for ND to work, o= r =0A> for=0A> another=0A>>>> protocol to replace it.=0A>>> =0A> =0A>>> ND = works fine, using link-local, one-hop multicasts.=A0 RPL =0A> need not=0A> = be=0A>>> involved.=0A>>> =0A>>> =0A> If someone wants to run RPL on a node = that uses neither ordinary ND=0A> =0A> or=0A>>> 6lowpan's version, then the= y will need some third variety of =0A> ND.=A0 I=0A> do=0A>>> not see why th= is is an issue for RPL to =0A> address.=A0 It seems quite out =0A>>> of sco= pe.=0A>>> =0A> =0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A> =A0 =A0 =A0 = =A0 =A0 =A0 -Richard Kelsey =0A>>> =0A> ___________________________________= ____________=0A>>> Roll mailing =0A> list=0A>>> > href=3D"mailto:Roll@ietf.= org">Roll@ietf.org=0A>>> > href=3D"https://www.ietf.org/mailman/listinfo/ro= ll" target=3D_blank =0A> >https://www.ietf.org/mailman/listinfo/roll=0A>>> = =0A>> =0A> =0A>> =0A>> =0A> _______________________________________________= =0A>> Roll mailing =0A> list=0A>> > href=3D"mailto:Roll@ietf.org">Roll@ietf= .org=0A>> > href=3D"https://www.ietf.org/mailman/listinfo/roll" target=3D_b= lank =0A> >https://www.ietf.org/mailman/listinfo/roll=0A> =0A> ____________= ___________________________________=0A> Roll mailing =0A> list=0A> > href= =3D"mailto:Roll@ietf.org">Roll@ietf.org=0A> > href=3D"https://www.ietf.org/= mailman/listinfo/roll" target=3D_blank =0A> >https://www.ietf.org/mailman/l= istinfo/roll=0A> =0A> _______________________________________________=0A> 6= lowpan mailing =0A> list=0A> > href=3D"mailto:6lowpan@ietf.org">6lowpan@iet= f.org=0A> > href=3D"https://www.ietf.org/mailman/listinfo/6lowpan" target= =3D_blank =0A> >https://www.ietf.org/mailman/listinfo/6lowpan=0A=0A-- =0AZa= ch Shelby, =0A> Head of Research, Sensinode Ltd.=0Ahttp://zachshelby.org=A0= - My blog "On =0A> the Internet of Things"=0Ahttp://6lowpan.net - My book = "6LoWPAN: The Wireless =0A> Embedded Internet"=0AMobile: +358 40 =0A> 77962= 97=0A=0A_______________________________________________=0A6lowpan =0A> mail= ing list=0A> href=3D"mailto:6lowpan@ietf.org">6lowpan@ietf.org=0A> href=3D"= https://www.ietf.org/mailman/listinfo/6lowpan" target=3D_blank =0A> >https:= //www.ietf.org/mailman/listinfo/6lowpan=0A=0A=0A From pthubert@cisco.com Wed May 5 10:28:03 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8433A6C28; Wed, 5 May 2010 10:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[AWL=-2.402, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou1Nir1R3HEk; Wed, 5 May 2010 10:28:01 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id B075428C0EC; Wed, 5 May 2010 10:26:18 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsBAMpG4UuQ/uCWiWdsb2JhbACdShUBAQEKCxERBhylFplhhRME X-IronPort-AV: E=Sophos;i="4.52,335,1270425600"; d="scan'208";a="6814730" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 05 May 2010 16:48:37 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o45HQ4er020749; Wed, 5 May 2010 17:26:04 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 May 2010 19:26:04 +0200 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: Wed, 5 May 2010 19:24:42 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01CD910D@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] how does a node get an IP address Thread-Index: AcrmpoOjTf0fKczJRTyzv8B1l61fYgAwZgEAATywzKAABuYsIA== References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , , "Richard Kelsey" X-OriginalArrivalTime: 05 May 2010 17:26:04.0369 (UTC) FILETIME=[0A21AC10:01CAEC78] Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 05 May 2010 17:28:03 -0000 Hi Mathilde: All good questions :) On top of Cartsen and Zach I may add that the router needs to know the address to be redistributed and the instance(s) in which to redistribute it. At the moment, we could redistribute into RPL addresses learnt from ND registrations (great) but we are missing the instanceID. Cheers, Pascal > -----Original Message----- > From: Mathilde Durvy (mdurvy) > Sent: Wednesday, May 05, 2010 4:19 PM > To: Pascal Thubert (pthubert); zach.shelby@sensinode.com; Richard Kelsey > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: RE: [Roll] how does a node get an IP address >=20 > Hi Pascal, >=20 > I fully agree with you. > In my opinion anything spanning multiple IP hops should not be done by ND. >=20 > On a related topic.... > 6lowpan network have the particularity that you cannot use on-link prefix > due to the non-transitivity of the wireless links. This means we need to > tell routers how to reach neighboring IPv6 hosts. So essentially 6lowpan-ND > is using a registration mechanism to establish a "route" between the router > and the host. > It is not clear to me whether this is the role of ND or of the routing > protocol. I think it could actually be both. > Hence the questions: > - Are IPv6 hosts possible in a 6lowpan network where the RPL protocol is > used? > - Should IPv6 hosts be part of a RPL topology (as leaf node) or should IPv6 > hosts use the 6lowpan-ND host-router spec? >=20 > Best, > Mathilde >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Pascal Thubert (pthubert) > Sent: jeudi, 29. avril 2010 09:01 > To: zach.shelby@sensinode.com; Richard Kelsey > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: Re: [Roll] how does a node get an IP address >=20 > Hi Zach: >=20 > I have yet to review the new ND-09 but my guts tell me that it is the wrong > place to do the job. Router to router is usually routing protocol land and > ND is definitely not a routing protocol. >=20 > The main question is how long can a router advertise a prefix, and the > answer is, as long as it is in the same subnet of an authoritative router > that owns the prefix. > Asserting the continuous reachability of the authoritative router is a > routing protocol problem. Maintaining a subnet together is the job for a new > form of Gateway Protocol, a Subnet Gateway Protocol RPL is just that. >=20 > Let see: >=20 > - Propagating the RA content is not an ND intrinsic problem, it only comes > with route over. And route over comes with a routing protocol. > - the route over protocol should be able to tie the route over subnetwork > together so it is a SGP. >=20 > So why can't we just say in 6LoWPAN ND that you for those who use it in > route over we expect an SGP to tie the route over subnetwork together and > that the SGP should transport the RA content, maintaining the validity with > the reachability of the authoritative router? I can write that text if you > wish. >=20 > It seems that we have a reasonable consensus in this thread to do exactly > that in RPL anyway... >=20 > Pascal >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > > zach.shelby@sensinode.com > > Sent: Tuesday, April 27, 2010 10:36 PM > > To: Richard Kelsey > > Cc: roll@ietf.org > > Subject: Re: [Roll] how does a node get an IP address > > > > Hi Everyone, > > > > Let me jump into this thread - just to make things more interesting > ;-) First, I > > recommend everyone goes and reads 6lowpan-nd-09 which was submitted > > today. When it comes to ND, you need to separate two interfaces. > > > > 1. The host-router interface > > > > Hosts know absolutely nothing about RPL (nor should they). Thus in > this case > > ND* does the job, and RS/RA is used for obtaining a prefix and > initializing its > > addresses. I think some people in the thread are referring to this. > > > > 2. The router-router interface > > > > As in RFC4861, in 6lowpan-nd-09 routers have more flexibility than > hosts in > > how they obtain prefix information (among other things). nd-09 does > include > > an optional technique for an authorative border router to disseminate > PIOs > > and CIOs (Context Information Options) between the border router and > all > > routers in the LoWPAN using RAs. It is actually a decent mechanism and > > improved over early versions. The draft clearly states that it is > optional as a > > routing algorithm may already do this. So Pascal is correct in that > respect. I > > haven't followed the thread well enough to have an opinion if RPL > should do > > that. > > > > Routers will also find other features of 6lowpan-nd-09 useful, for > example > > during initial bootstrapping, to maintain their default router and > neighbor > > caches, avoid the need for address resolution, and to perform NUD. The > > draft (tries to) clearly state when features are required or optional > for a > > router. > > > > Zach > > > > > > >> From: Michael Richardson > > >> Date: Tue, 27 Apr 2010 10:38:47 -0400 > > >> > > >> >>>>> "Richard" =3D=3D Richard Kelsey > writes: > > >> >> Date: Tue, 27 Apr 2010 14:18:32 +0200 From: "Pascal Thubert > > >> >> (pthubert)" > > >> >> > > >> >> The question here is that the authoritative routers need to > > >> >> disseminate the PIO (and the RIO) to all routers in the > subnet. > > >> > > >> Richard> How do other routing protocols (OSPF, IS-IS, AODV, > OLSR) > > >> > > >> I can only speak for OSPF and ISIS. > > >> Neither deal with multi-hop subnets or with any kind of address > > >> assignment. > > > > > > Why should RPL be any different? Yes, it will be run on multi-hop > > > subnets, but I still do not see how this affects the routing. > > > > > >> Both were written when multicast was very new. > > > > > > I am not sure how RPL's handling of multicast matters here. > > > While RPL is required to route multi-hop multicasts, ND uses > > > link-local multicasts, which do not require routing. > > > > > >> Richard> I understand that multi-hop subnets are a problem for ND, > > >> Richard> but I don't see how the routing protocol is affected. > > >> > > >> RPL either requires 6lowpan, or it doesn't. > > > > > > RPL should work fine with ordinary ND. Why would it require > 6lowpan? > > > > > >> If it doesn't, then it has to provide for ND to work, or for > another > > >> protocol to replace it. > > > > > > ND works fine, using link-local, one-hop multicasts. RPL need not > be > > > involved. > > > > > > If someone wants to run RPL on a node that uses neither ordinary ND > or > > > 6lowpan's version, then they will need some third variety of ND. I > do > > > not see why this is an issue for RPL to address. It seems quite out > > > of scope. > > > > > > -Richard Kelsey > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll > > > > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Wed May 5 22:39:11 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A0F23A69B2; Wed, 5 May 2010 22:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.731 X-Spam-Level: X-Spam-Status: No, score=-7.731 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2p8KGQomYDl; Wed, 5 May 2010 22:39:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5A1963A691A; Wed, 5 May 2010 22:39:10 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANPy4UurR7H+/2dsb2JhbACdZXGiK5lhhRME X-IronPort-AV: E=Sophos;i="4.52,339,1270425600"; d="scan'208";a="525692740" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 06 May 2010 05:38:57 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o465cufQ008867; Thu, 6 May 2010 05:38:57 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 07:38:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 May 2010 07:38:51 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: AcrsafaQTbCEujbNSpmpgGIEd7kLcgAcyA7A References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 06 May 2010 05:38:56.0041 (UTC) FILETIME=[6B4A5990:01CAECDE] Cc: roll@ietf.org, zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 06 May 2010 05:39:12 -0000 Hi Carsten: Fact is, the latest 6LoWPAN ND draft does not support mesh under since it lost the white board piece. It does not support route over either since it is not compatible with the only route over protocol in existence. That's very far from what the group voted in Dublin when it elected the backbone router draft as WG doc. At the moment, I see 2 possible directions for 6LoWPAN ND: - Pack it an Indiana Jones RFC and hide it in the midst of 6000 other boxes where it will be mostly harmless. - Roll back to where we were before Hiroshima and work closely with RPL to build a consistent solution for route over. The ball is in your camp. Pascal > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Wednesday, May 05, 2010 5:44 PM > To: Mathilde Durvy (mdurvy) > Cc: Pascal Thubert (pthubert); zach.shelby@sensinode.com; Richard Kelsey; > roll@ietf.org; 6lowpan@ietf.org > Subject: Re: [6lowpan] [Roll] how does a node get an IP address >=20 > > On a related topic.... > > 6lowpan network have the particularity that you cannot use on-link > > prefix due to the non-transitivity of the wireless links. This means > > we need to tell routers how to reach neighboring IPv6 hosts. So > > essentially 6lowpan-ND is using a registration mechanism to establish > > a "route" between the router and the host. > > It is not clear to me whether this is the role of ND >=20 > The role of ND here is doing the host-router neighbor discovery. >=20 > > or of the routing > > protocol. >=20 > The role of RPL here is to disseminate the host route on towards other > routers. >=20 > > I think it could actually be both. >=20 > Hosts should not need to speak routing protocols. >=20 > > Hence the questions: > > - Are IPv6 hosts possible in a 6lowpan network where the RPL protocol > > is used? >=20 > I would consider it a major failure if RPL didn't support networks with hosts. > (Networks without hosts, i.e., all-router networks, are certainly possible, but > in a constrained node/network we are talking about a relatively high lower > bound on the complexity of nodes or a *very* simple routing protocol. > Of course, the routing protocol could distinguish three instead of two > complexity classes of nodes, supporting something like a "stub router" [a > router that cannot forward]. Still, that class would need to implement some > parts of the routing protocol, imposing constraints either way or both.) >=20 > > - Should IPv6 hosts be part of a RPL topology (as leaf node) or should > > IPv6 hosts use the 6lowpan-ND host-router spec? >=20 > As I said, hosts shouldn't need to speak RPL. >=20 > Gruesse, Carsten From pthubert@cisco.com Wed May 5 23:21:50 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA523A69E2; Wed, 5 May 2010 23:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.742 X-Spam-Level: X-Spam-Status: No, score=-7.742 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WY8nDdswjAz; Wed, 5 May 2010 23:21:48 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 412853A6AB5; Wed, 5 May 2010 23:21:43 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG784UurR7Hu/2dsb2JhbACdZXGiMplphRME X-IronPort-AV: E=Sophos;i="4.52,339,1270425600"; d="scan'208";a="193240017" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 06 May 2010 06:21:27 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o466LQMs024469; Thu, 6 May 2010 06:21:27 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 08:21:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 May 2010 08:21:22 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01CD91C8@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: AcrsaY0zfE5WrZdkQNe7kcLeLlypPgAdQTyQ References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 06 May 2010 06:21:25.0823 (UTC) FILETIME=[5B1434F0:01CAECE4] Cc: roll@ietf.org, zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 06 May 2010 06:21:50 -0000 Hi Zach: >=20 > > Hi Pascal, > > > > I fully agree with you. > > In my opinion anything spanning multiple IP hops should not be done by > ND. >=20 > That logic doesn't work anymore with route-over LoWPANs. As the prefixes > are spanning the whole LoWPAN there is a natural need for ND to help with > that. In the case of RPL, the WG may decide to disseminate some things such > as prefix information between routers in a LoWPAN using the routing > protocol. 6lowpan-nd-09 states clearly that you may do that, so nothing > stopping RPL there. What is this argument about? You are complaining about > something that is not a problem? >=20 > Now RPL isn't the only routing protocol.... 6lowpan-nd-09 provides an > optional mechanism of using RS/RA for disseminating prefix and context > information between all routers in a LoWPAN that is routing protocol > independent. Regardless of RPL, this will surely come in handy and some > routing protocols may even specify to use this mechanism. [Pascal]=20 Dissemination is the easy piece in the routing protocol. The hard piece is maintenance. If you try to maintain the connectivity within the subnet, you end up building an SGP like RPL. Do you really want to rediscover what we've been through? > Let me remind you of how RPL started by the way. In the beginning the idea > was to piggyback RPL information on ND traffic as there were already similar > flows. Eventually the WG decided to give RPL its own messages instead of > piggybacking as ND options. Now it has gone to the extreme of RPL being the [Pascal]=20 Both the ROLL fundamentals and the backbone router drafts extended ND.=20 ROLL Fundamentals inherited from the NINA model that was a recursive host to router model (NINA meant Network In Node). The goal was to have a consistent host to router interface all the way up the DAG. We split the work between 2 stove pipes and that spirit was lost.=20 > one and only protocol and everything must be carried on that.... Quite a > change! Next we could piggyback DHCPv6 on RPL, use RPL for DAD, and what > the heck, let's go for DNS too... Starts to sound like a shopping-TV ad for a > super-vegetable-processing-miracle doesn't it? [Pascal] This is the direct consequence of keeping 6LoWPAN and RPL apart. None can refer to / depend on the other. On the ROLL side: RPL needs all nodes to be routers so it can claim it does not need ND. Truth is, a RPL node still requires ND for address allocation. On the 6LoWPAN side: ND is partial solution with no applicability in the real world. Truth is, 6LoWPAN ND needs RPL for tying the subnet together. > > > > On a related topic.... > > 6lowpan network have the particularity that you cannot use on-link > > prefix due to the non-transitivity of the wireless links. This means > > we need to tell routers how to reach neighboring IPv6 hosts. So > > essentially 6lowpan-ND is using a registration mechanism to establish > > a "route" between the router and the host. >=20 > It is actually letting the host and router know about each other (router > discovery), their reachability (NUD) and their L2 addresses (address > resolution). These are all standard features of ND. >=20 > > It is not clear to me whether this is the role of ND or of the routing > > protocol. I think it could actually be both. > > Hence the questions: > > - Are IPv6 hosts possible in a 6lowpan network where the RPL protocol > > is used? >=20 > Better be, or you just broke an important model of IPv6. I would say it MUST > be possible for hosts to attach to a LoWPAN running RPL (and stay blissfully > ignorant of RPL). [Pascal].=20 If you look at it, the IP header is the abstraction of a set of instructions by the end point to the routing fabric. The flow label is an integral part of that abstraction and RPL makes use of it to select an instance. This capability is much needed in a LLN a host connected to a RPL network should be able to make use of it. A given deployment can always resort to instance 0 to accept nodes that are not RPL aware at all.. =20 > > - Should IPv6 hosts be part of a RPL topology (as leaf node) or should > > IPv6 hosts use the 6lowpan-ND host-router spec? >=20 > ND is clearly the standard host-router interface regardless of IPv6 or > 6LoWPAN. Forcing hosts to know anything about RPL would be insane... [Pascal] Just as incorporating a routing protocol in ND would be. 6LoWPAN managed to work with ISA100. ROLL managed to work with ZigBee IP. Can't 6LoWPAN and ROLL manage to work together now? Pascal From cabo@tzi.org Wed May 5 23:47:12 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1946D3A6AF0; Wed, 5 May 2010 23:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud8+XuHiKC46; Wed, 5 May 2010 23:47:11 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id B91C93A6AE3; Wed, 5 May 2010 23:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o466kk2X001427; Thu, 6 May 2010 08:46:46 +0200 (CEST) Received: from [192.168.217.101] (p5489BAFC.dip.t-dialin.net [84.137.186.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 67ED8D27D; Thu, 6 May 2010 08:46:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> Date: Thu, 6 May 2010 08:46:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1078) Cc: ROLL WG , zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 06 May 2010 06:47:12 -0000 Pascal, I presume you are talking about=20 draft-ietf-6lowpan-nd-09.txt Can you be a bit more specific? > Fact is, the latest 6LoWPAN ND draft does not support mesh under since > it lost the white board piece. -09 has significantly less functionality than -08 had. (This may be a bit disappointing to some of us, but it clearly was the = result of IETF77.) I'm not sure how that more focused functionality makes it "not support = mesh under". Did we lose some functionality that is required? Please explain. > It does not support route over either since it is not compatible with > the only route over protocol in existence. Again, please explain. > [...] work closely with RPL > to build a consistent solution for route over. Yes! (That's why I kept ROLL on the CC.) If there is a technical issue, we need to understand it, so please = explain. Gruesse, Carsten From pthubert@cisco.com Thu May 6 00:03:04 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201723A69E2; Thu, 6 May 2010 00:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[AWL=-3.106, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-EwknrGGeVQ; Thu, 6 May 2010 00:03:02 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 7185F3A6AE4; Thu, 6 May 2010 00:02:58 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwCAPwG4kuQ/uCWiWdsb2JhbACdaBUBAQsLEREGHKJGmWyFEwQ X-IronPort-AV: E=Sophos;i="4.52,339,1270425600"; d="scan'208";a="6840705" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 06 May 2010 06:25:07 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4672Ydi021419; Thu, 6 May 2010 07:02:37 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 09:02:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 May 2010 09:02:28 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: Acrs5/WZwIt4J/QMRUuHVYOWR9M1dQAAXYfA References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 06 May 2010 07:02:32.0441 (UTC) FILETIME=[194C3E90:01CAECEA] Cc: ROLL WG , zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 06 May 2010 07:03:04 -0000 Hi Carsten > -09 has significantly less functionality than -08 had. > (This may be a bit disappointing to some of us, but it clearly was the result of > IETF77.) I'm not sure how that more focused functionality makes it "not > support mesh under". > Did we lose some functionality that is required? > Please explain. [Pascal] this piece is not related to ROLL. This is about the multicast issue in mesh under. 6LoWPAN elected the backbone router draft to address that issue. >=20 > > It does not support route over either since it is not compatible with > > the only route over protocol in existence. > > Again, please explain. [Pascal] 6LoWPAN ND needs some addition to enable RPL aware hosts. In particular around instance IDs.=20 >=20 > > [...] work closely with RPL > > to build a consistent solution for route over. >=20 > Yes! (That's why I kept ROLL on the CC.) If there is a technical issue, we need > to understand it, so please explain. >=20 [Pascal]=20 The RPL instance decision is end to end and matches the application requirements. A device might send traffic over multiple instances and it has to indicate that in the flow label. What I'm proposing is to recognize that a LoWPAN and an LLN are quite the same thing, and if they were not, make it so from now on. At that point we can accept that ROLL and split the job between RPL and ND, RPL doing the router to router piece and ND the interface to the hosts. =20 On the RPL side, that means transporting RIO and PIO from the authoritative router acting as root down the RPL fabric within DIO messages. It's a simple replacement to the existing Destination Prefix option in DIO, no harm done. You'll note that RPL actually USES that information. On the ND side, it means opening the messages to RPL parameters, in particular the mapping between the flow label and the instance information. RAs should be able to advertise which instance is available from a given router for instance. We were almost there with ND 07. So sad. Also sad that you took me off the draft btw, won't help me internally. And then, ND can defer to 'an SGP such as RPL' for PIO/RIO dissemination and RPL routers can be configured to redistribute host information leant from ND into the SGP. > Gruesse, Carsten From cabo@tzi.org Thu May 6 01:05:15 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD8E028C172; Thu, 6 May 2010 01:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.791 X-Spam-Level: X-Spam-Status: No, score=-5.791 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3LPHk5Mqn7W; Thu, 6 May 2010 01:05:09 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id 17C2728C118; Thu, 6 May 2010 01:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o4684FDf000304; Thu, 6 May 2010 10:04:15 +0200 (CEST) Received: from [192.168.217.101] (p5489BAFC.dip.t-dialin.net [84.137.186.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id F212FD2F3; Thu, 6 May 2010 10:04:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> Date: Thu, 6 May 2010 10:04:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <675EB7B8-FA26-4C99-85AE-ECEEF22F8FF0@tzi.org> References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1078) Cc: ROLL WG , zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a node get an IP address) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 06 May 2010 08:05:16 -0000 On May 6, 2010, at 09:02, Pascal Thubert (pthubert) wrote: > enable RPL aware hosts Should we? (Obviously, if a node really needs to know about RPL, it can always = become a router.) If I understand you correctly, this is about hosts selecting a specific = RPL instance-ID for outgoing traffic. Traditionally, IP has used the TOS byte (Traffic Class in IPv6) to = select between different behaviors of the forwarding system. What is it = that the host wants to say by selecting a specific RPL instance ID? Why = can't the router make that selection, e.g. based on the Traffic Class = and the destination address? (Another interesting question is, for incoming traffic, how a host = selects which instances it wants to be part of. Is that even a useful = thing to do? Would that selection be made by the host, by its first-hop = router, or by some configuration agent?) It would be useful to get more information about how instance-IDs are = intended to be used with RPL. On the protocol side: If there really is something that a host needs to know about = RPL-specific information (instances or whatever), this could be = delivered in an ND option that could very well be defined in an = RPL-related document, no need to define it in 6LoWPAN-ND. Another way = to set up this information would be to configure it during commissioning = or using a host configuration protocol like DHCP. Gruesse, Carsten From abr@sdesigns.dk Thu May 6 01:49:44 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B633A68B1; Thu, 6 May 2010 01:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ft7HPDybmb0J; Thu, 6 May 2010 01:49:43 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 4B4BD3A6896; Thu, 6 May 2010 01:49:43 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 May 2010 10:49:29 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A10E@zensys17.zensys.local> In-Reply-To: <675EB7B8-FA26-4C99-85AE-ECEEF22F8FF0@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll][6lowpan] how does a node get an IPaddress Thread-Index: Acrs8xHMGhxhHUPjQz+laYTqrlmmkAAAy/2w References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi><6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> <675EB7B8-FA26-4C9 9-85AE-E CEEF22F8FF0@tzi.org> From: "Anders Brandt" To: "Carsten Bormann" , "Pascal Thubert (pthubert)" Cc: ROLL WG , zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IPaddress X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 06 May 2010 08:49:44 -0000 Let me try one more time: How much of this will I have to implement to be compliant with other LLN/RPL nodes? In a home control/building environment, the notion of a router nodes is rather artificial. I may have _host_nodes_. They are host nodes because they are sleeping (battery operated) and therefore they cannot participate in routing. They still have to get an IP address to talk to other IP hosts. Alternatively, I may have combined _host&router_nodes_ which serve a purpose application-wise and at the same time happen to be routing resources. Do these hosts have to use another way of getting IP addresses just because they happen to be able to do routing? >From a designer's standpoint it does not seem quite elegant that I have to do use different methods depending on the power model for my node. Am I missing something here? Thanks, Anders > -----Original Message----- > From: 6lowpan-bounces@ietf.org=20 > [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Thursday, May 06, 2010 10:04 > To: Pascal Thubert (pthubert) > Cc: ROLL WG; zach.shelby@sensinode.com; 6lowpan@ietf.org > Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a=20 > node get an IPaddress) >=20 > On May 6, 2010, at 09:02, Pascal Thubert (pthubert) wrote: >=20 > > enable RPL aware hosts >=20 > Should we? >=20 > (Obviously, if a node really needs to know about RPL, it can=20 > always become a router.) >=20 > If I understand you correctly, this is about hosts selecting=20 > a specific RPL instance-ID for outgoing traffic. > Traditionally, IP has used the TOS byte (Traffic Class in=20 > IPv6) to select between different behaviors of the forwarding=20 > system. What is it that the host wants to say by selecting a=20 > specific RPL instance ID? Why can't the router make that=20 > selection, e.g. based on the Traffic Class and the=20 > destination address? >=20 > (Another interesting question is, for incoming traffic, how a=20 > host selects which instances it wants to be part of. Is that=20 > even a useful thing to do? Would that selection be made by=20 > the host, by its first-hop router, or by some configuration agent?) >=20 > It would be useful to get more information about how=20 > instance-IDs are intended to be used with RPL. >=20 > On the protocol side: > If there really is something that a host needs to know about=20 > RPL-specific information (instances or whatever), this could=20 > be delivered in an ND option that could very well be defined=20 > in an RPL-related document, no need to define it in=20 > 6LoWPAN-ND. Another way to set up this information would be=20 > to configure it during commissioning or using a host=20 > configuration protocol like DHCP. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 From richard.kelsey@ember.com Thu May 6 05:26:37 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09FC23A6B6A; Thu, 6 May 2010 05:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgLSEGQWc+12; Thu, 6 May 2010 05:26:36 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 3CA103A6BAE; Thu, 6 May 2010 05:22:58 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 08:26:04 -0400 Date: Thu, 06 May 2010 08:16:30 -0400 Message-Id: <87zl0dz0m9.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 06 May 2010 12:26:04.0382 (UTC) FILETIME=[4BB75FE0:01CAED17] Cc: cabo@tzi.org, zach.shelby@sensinode.com, roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 06 May 2010 12:26:37 -0000 > Date: Thu, 6 May 2010 09:02:28 +0200 > From: "Pascal Thubert (pthubert)" > > [Pascal] 6LoWPAN ND needs some addition to enable RPL aware hosts. In > particular around instance IDs. Pascal, I disagree with "needs". The ability to select an instance ID for a particular message is an optional extra. RPL works fine without it. I am okay with limiting instance ID selection to routers. -Richard Kelsey From robert.cragie@gridmerge.com Thu May 6 10:39:13 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C1028C123; Thu, 6 May 2010 10:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th-p+6OS8w5T; Thu, 6 May 2010 10:39:11 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 6B8AB3A6B59; Thu, 6 May 2010 10:39:09 -0700 (PDT) Received: from [12.188.45.3] (helo=[198.19.179.250]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OA51w-0000Y3-Ln; Thu, 06 May 2010 18:38:54 +0100 Message-ID: <4BE2FE81.5040600@gridmerge.com> Date: Thu, 06 May 2010 18:38:09 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org, 6lowpan <6lowpan@ietf.org> References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060703010907010107090905" Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 17:39:13 -0000 This is a cryptographically signed message in MIME format. --------------ms060703010907010107090905 Content-Type: multipart/alternative; boundary="------------010702070003070808080307" This is a multi-part message in MIME format. --------------010702070003070808080307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Zach, I agree with some of what you say but not all of it. See inline=20 comments. In a nutshell: * We need ND for bootstrapping hosts and routers and to maintain hosts. I think nd-09 supports this well * Hosts do not need to know anything about routing protocol used in the wider network * There is nothing wrong with using RPL's (or any other routing protocol) implicit multicast mechanism for disseminating lowpan wide information Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 05/05/2010 4:42 PM, Zach Shelby wrote: > Hi, > > On May 5, 2010, at 17:18 , Mathilde Durvy (mdurvy) wrote: > > =20 >> Hi Pascal, >> >> I fully agree with you. >> In my opinion anything spanning multiple IP hops should not be done by= ND. >> =20 > That logic doesn't work anymore with route-over LoWPANs. As the prefixe= s are spanning the whole LoWPAN there is a natural need for ND to help wi= th that. (1) I repeat - classic ND has no concept over this, so there isn't=20 a natural need for ND to help with this. There has been a choice to add=20 in a mechanism but that mechanism is a 'multicast' mechanism which=20 implicitly has to define propagation. Propagation is not the domain of=20 ND but is the domain of the associated routing protocol > In the case of RPL, the WG may decide to disseminate some things such= as prefix information between routers in a LoWPAN using the routing prot= ocol. 6lowpan-nd-09 states clearly that you may do that, so nothing stopp= ing RPL there. What is this argument about? You are complaining about som= ething that is not a problem? > =20 The way it is worded in nd-09 is fine with me, so I have no=20 argument :-) > Now RPL isn't the only routing protocol.... 6lowpan-nd-09 provides an o= ptional mechanism of using RS/RA for disseminating prefix and context inf= ormation between all routers in a LoWPAN that is routing protocol indepen= dent. Regardless of RPL, this will surely come in handy and some routing = protocols may even specify to use this mechanism. > =20 See comment (1) above > Let me remind you of how RPL started by the way. In the beginning the i= dea was to piggyback RPL information on ND traffic as there were already = similar flows. Eventually the WG decided to give RPL its own messages ins= tead of piggybacking as ND options. Piggybacking RPL options on ND was never going to work as it is=20 back-to-front, same as comment (1) above. > Now it has gone to the extreme of RPL being the one and only protocol a= nd everything must be carried on that.... Quite a change! Next we could p= iggyback DHCPv6 on RPL, use RPL for DAD, and what the heck, let's go for = DNS too... Starts to sound like a shopping-TV ad for a super-vegetable-pr= ocessing-miracle doesn't it? > =20 What is 'it' ("Now it has gone..."). RPL provides a natural=20 propagation mechanism to all routers so please tell me what is wrong=20 with utilising that to disseminate network-wide information? > =20 >> On a related topic.... >> 6lowpan network have the particularity that you cannot use on-link pre= fix >> due to the non-transitivity of the wireless links. This means we need = to >> tell routers how to reach neighboring IPv6 hosts. So essentially 6lowp= an-ND >> is using a registration mechanism to establish a "route" between the r= outer >> and the host. >> =20 > It is actually letting the host and router know about each other (route= r discovery), their reachability (NUD) and their L2 addresses (address re= solution). These are all standard features of ND. > =20 I agree here - we need ND for host - router interaction and indeed=20 for bootstrapping a router onto the lowpan > =20 >> It is not clear to me whether this is the role of ND or of the routing= >> protocol. I think it could actually be both. >> Hence the questions: >> - Are IPv6 hosts possible in a 6lowpan network where the RPL protocol = is >> used? >> =20 > Better be, or you just broke an important model of IPv6. I would say it= MUST be possible for hosts to attach to a LoWPAN running RPL (and stay b= lissfully ignorant of RPL). > =20 I agree too > =20 >> - Should IPv6 hosts be part of a RPL topology (as leaf node) or should= IPv6 >> hosts use the 6lowpan-ND host-router spec? >> =20 > ND is clearly the standard host-router interface regardless of IPv6 or = 6LoWPAN. Forcing hosts to know anything about RPL would be insane... > =20 I agree. Hosts should not need to know anything about which routing = protocol is in use in the wider lowpan > Zach > > =20 >> Best, >> Mathilde >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf O= f >> Pascal Thubert (pthubert) >> Sent: jeudi, 29. avril 2010 09:01 >> To: zach.shelby@sensinode.com; Richard Kelsey >> Cc: roll@ietf.org; 6lowpan@ietf.org >> Subject: Re: [Roll] how does a node get an IP address >> >> Hi Zach: >> >> I have yet to review the new ND-09 but my guts tell me that it is the = wrong >> place to do the job. Router to router is usually routing protocol land= and >> ND is definitely not a routing protocol. >> >> The main question is how long can a router advertise a prefix, and th= e >> answer is, as long as it is in the same subnet of an authoritative rou= ter >> that owns the prefix. >> Asserting the continuous reachability of the authoritative router is a= >> routing protocol problem. Maintaining a subnet together is the job for= a new >> form of Gateway Protocol, a Subnet Gateway Protocol RPL is just that. >> >> Let see: >> >> - Propagating the RA content is not an ND intrinsic problem, it only = comes >> with route over. And route over comes with a routing protocol. >> - the route over protocol should be able to tie the route over subnetw= ork >> together so it is a SGP. >> >> So why can't we just say in 6LoWPAN ND that you for those who use it i= n >> route over we expect an SGP to tie the route over subnetwork together = and >> that the SGP should transport the RA content, maintaining the validity= with >> the reachability of the authoritative router? I can write that text if= you >> wish. >> >> It seems that we have a reasonable consensus in this thread to do exac= tly >> that in RPL anyway... >> >> Pascal >> >> =20 >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>> =20 >> Of >> =20 >>> zach.shelby@sensinode.com >>> Sent: Tuesday, April 27, 2010 10:36 PM >>> To: Richard Kelsey >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] how does a node get an IP address >>> >>> Hi Everyone, >>> >>> Let me jump into this thread - just to make things more interesting >>> =20 >> ;-) First, I >> =20 >>> recommend everyone goes and reads 6lowpan-nd-09 which was submitted >>> today. When it comes to ND, you need to separate two interfaces. >>> >>> 1. The host-router interface >>> >>> Hosts know absolutely nothing about RPL (nor should they). Thus in >>> =20 >> this case >> =20 >>> ND* does the job, and RS/RA is used for obtaining a prefix and >>> =20 >> initializing its >> =20 >>> addresses. I think some people in the thread are referring to this. >>> >>> 2. The router-router interface >>> >>> As in RFC4861, in 6lowpan-nd-09 routers have more flexibility than >>> =20 >> hosts in >> =20 >>> how they obtain prefix information (among other things). nd-09 does >>> =20 >> include >> =20 >>> an optional technique for an authorative border router to disseminate= >>> =20 >> PIOs >> =20 >>> and CIOs (Context Information Options) between the border router and >>> =20 >> all >> =20 >>> routers in the LoWPAN using RAs. It is actually a decent mechanism an= d >>> improved over early versions. The draft clearly states that it is >>> =20 >> optional as a >> =20 >>> routing algorithm may already do this. So Pascal is correct in that >>> =20 >> respect. I >> =20 >>> haven't followed the thread well enough to have an opinion if RPL >>> =20 >> should do >> =20 >>> that. >>> >>> Routers will also find other features of 6lowpan-nd-09 useful, for >>> =20 >> example >> =20 >>> during initial bootstrapping, to maintain their default router and >>> =20 >> neighbor >> =20 >>> caches, avoid the need for address resolution, and to perform NUD. Th= e >>> draft (tries to) clearly state when features are required or optional= >>> =20 >> for a >> =20 >>> router. >>> >>> Zach >>> >>> >>> =20 >>>>> From: Michael Richardson >>>>> Date: Tue, 27 Apr 2010 10:38:47 -0400 >>>>> >>>>> =20 >>>>>>>>>> "Richard" =3D=3D Richard Kelsey >>>>>>>>>> =20 >> writes: >> =20 >>>>>>> Date: Tue, 27 Apr 2010 14:18:32 +0200 From: "Pascal Thubert >>>>>>> (pthubert)" >>>>>>> >>>>>>> The question here is that the authoritative routers need to >>>>>>> disseminate the PIO (and the RIO) to all routers in the >>>>>>> =20 >> subnet. >> =20 >>>>> Richard> How do other routing protocols (OSPF, IS-IS, AODV, >>>>> =20 >> OLSR) >> =20 >>>>> I can only speak for OSPF and ISIS. >>>>> Neither deal with multi-hop subnets or with any kind of address >>>>> assignment. >>>>> =20 >>>> Why should RPL be any different? Yes, it will be run on multi-hop >>>> subnets, but I still do not see how this affects the routing. >>>> >>>> =20 >>>>> Both were written when multicast was very new. >>>>> =20 >>>> I am not sure how RPL's handling of multicast matters here. >>>> While RPL is required to route multi-hop multicasts, ND uses >>>> link-local multicasts, which do not require routing. >>>> >>>> =20 >>>>> Richard> I understand that multi-hop subnets are a problem for ND,= >>>>> Richard> but I don't see how the routing protocol is affected. >>>>> >>>>> RPL either requires 6lowpan, or it doesn't. >>>>> =20 >>>> RPL should work fine with ordinary ND. Why would it require >>>> =20 >> 6lowpan? >> =20 >>>> =20 >>>>> If it doesn't, then it has to provide for ND to work, or for >>>>> =20 >> another >> =20 >>>>> protocol to replace it. >>>>> =20 >>>> ND works fine, using link-local, one-hop multicasts. RPL need not >>>> =20 >> be >> =20 >>>> involved. >>>> >>>> If someone wants to run RPL on a node that uses neither ordinary ND >>>> =20 >> or >> =20 >>>> 6lowpan's version, then they will need some third variety of ND. I >>>> =20 >> do >> =20 >>>> not see why this is an issue for RPL to address. It seems quite out= >>>> of scope. >>>> >>>> -Richard Kelsey >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> =20 >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> =20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> =20 > =20 --------------010702070003070808080307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Zach,

I agree with some of what you say but not all of it. See inline comments. In a nutshell:
  • We need ND for bootstrapping hosts and routers and to maintain hosts. I think nd-09 supports this well
  • Hosts do not need to know anything about routing protocol used in the wider network
  • There is nothing wrong with using RPL's (or any other routing protocol) implicit multicast mechanism for disseminating lowpan wide information
Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com


On 05/05/2010 4:42 PM, Zach Shelby wrote: 
Hi,

On May 5, 2010, at 17:18 , Mathilde Durvy (mdurvy) wrote:

  
Hi Pascal,

I fully agree with you.
In my opinion anything spanning multiple IP hops should not be done by ND=
=2E
    
That logic doesn't work anymore with route-over LoWPANs. As the prefixes =
are spanning the whole LoWPAN there is a natural need for ND to help with=
 that.
<RCC>(1) I repeat - classic ND has no concept over this, so there isn't a natural need for ND to help with this. There has been a choice to add in a mechanism but that mechanism is a 'multicast' mechanism which implicitly has to define propagation. Propagation is not the domain of ND but is the domain of the associated routing protocol</RCC>
 In the case of RPL, the WG may decide to disseminate so=
me things such as prefix information between routers in a LoWPAN using th=
e routing protocol. 6lowpan-nd-09 states clearly that you may do that, so=
 nothing stopping RPL there. What is this argument about? You are complai=
ning about something that is not a problem?=20
<RCC>The way it is worded in nd-09 is fine with me, so I have no argument :-)</RCC>
Now RPL isn't the only routing protocol.... 6lowpan-nd-09 provides an opt=
ional mechanism of using RS/RA for disseminating prefix and context infor=
mation between all routers in a LoWPAN that is routing protocol independe=
nt. Regardless of RPL, this will surely come in handy and some routing pr=
otocols may even specify to use this mechanism. =20
<RCC>See comment (1) above</RCC> 
Let me remind you of how RPL started by the way. In the beginning the ide=
a was to piggyback RPL information on ND traffic as there were already si=
milar flows. Eventually the WG decided to give RPL its own messages inste=
ad of piggybacking as ND options.
<RCC>Piggybacking RPL options on ND was never going to work as it is back-to-front, same as comment (1) above.<RCC> 
Now it has gone to the extreme of RPL being the one and =
only protocol and everything must be carried on that.... Quite a change! =
Next we could piggyback DHCPv6 on RPL, use RPL for DAD, and what the heck=
, let's go for DNS too... Starts to sound like a shopping-TV ad for a sup=
er-vegetable-processing-miracle doesn't it?=20
<RCC>What is 'it' ("Now it has gone..."). RPL provides a natural propagation mechanism to all routers so please tell me what is wrong with utilising that to disseminate network-wide information?</RCC><= br> 
  
On a related topic....
6lowpan network have the particularity that you cannot use on-link prefix=

due to the non-transitivity of the wireless links. This means we need to
tell routers how to reach neighboring IPv6 hosts. So essentially 6lowpan-=
ND
is using a registration mechanism to establish a "route" between the rout=
er
and the host. =20
    
It is actually letting the host and router know about each other (router =
discovery), their reachability (NUD) and their L2 addresses (address reso=
lution). These are all standard features of ND.
<RCC>I agree here - we need ND for host - router interaction and indeed for bootstrapping a router onto the lowpan</RCC>
  
It is not clear to me whether this is the role of ND o=
r of the routing
protocol. I think it could actually be both.=20
Hence the questions:=20
- Are IPv6 hosts possible in a 6lowpan network where the RPL protocol is
used?
    
Better be, or you just broke an important model of IPv6. I would say it M=
UST be possible for hosts to attach to a LoWPAN running RPL (and stay bli=
ssfully ignorant of RPL).=20
<RCC>I agree too</RCC>
  
- Should IPv6 hosts be part of a RPL topology (as leaf=
 node) or should IPv6
hosts use the 6lowpan-ND host-router spec?
    
ND is clearly the standard host-router interface regardless of IPv6 or 6L=
oWPAN. Forcing hosts to know anything about RPL would be insane...=20
<RCC>I agree. Hosts should not need to know anything about which routing protocol is in use in the wider lowpan</RCC>
Zach

  
Best,
Mathilde=20

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf Of
Pascal Thubert (pthubert)
Sent: jeudi, 29. avril 2010 09:01
To: zach.shelby@sensinode.com; Richard Kelsey
Cc: r=
oll@ietf.org; 6lowpan@ietf.org
Subject: Re: [Roll] how does a node get an IP address

Hi Zach:

I have yet to review the new ND-09 but my guts tell me that it is the wro=
ng
place to do the job. Router to router is usually routing protocol land an=
d
ND is definitely not a routing protocol.

The main question is how long can  a router advertise a prefix, and the
answer is, as long as it is in the same subnet of an authoritative router=

that owns the prefix.
Asserting the continuous reachability of the authoritative router is a
routing protocol problem. Maintaining a subnet together is the job for a =
new
form of Gateway Protocol, a Subnet Gateway Protocol RPL is just that.

Let see:

- Propagating the RA content is not an ND intrinsic  problem, it only com=
es
with route over. And route over comes with a routing protocol.
- the route over protocol should be able to tie the route over subnetwork=

together so it is a SGP.

So why can't we just say in 6LoWPAN ND that you for those who use it in
route over we expect an SGP to tie the route over subnetwork together and=

that the SGP should transport the RA content, maintaining the validity wi=
th
the reachability of the authoritative router? I can write that text if yo=
u
wish.

It seems that we have a reasonable consensus in this thread to do exactly=

that in RPL anyway...

Pascal

    
-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf
      
Of
    
zach.shelby@sensinode.com
Sent: Tuesday, April 27, 2010 10:36 PM
To: Richard Kelsey
Cc: r=
oll@ietf.org
Subject: Re: [Roll] how does a node get an IP address

Hi Everyone,

Let me jump into this thread - just to make things more interesting
      
;-) First, I
    
recommend everyone goes and reads 6lowpan-nd-09 whic=
h was submitted=20
today. When it comes to ND, you need to separate two interfaces.

1. The host-router interface

Hosts know absolutely nothing about RPL (nor should they). Thus in
      
this case
    
ND* does the job, and RS/RA is used for obtaining a =
prefix and
      
initializing its
    
addresses. I think some people in the thread are ref=
erring to this.

2. The router-router interface

As in RFC4861, in 6lowpan-nd-09 routers have more flexibility than
      
hosts in
    
how they obtain prefix information (among other thin=
gs). nd-09 does
      
include
    
an optional technique for an authorative border rout=
er to disseminate
      
PIOs
    
and CIOs (Context Information Options) between the b=
order router and
      
all
    
routers in the LoWPAN using RAs. It is actually a de=
cent mechanism and=20
improved over early versions. The draft clearly states that it is
      
optional as a
    
routing algorithm may already do this. So Pascal is =
correct in that
      
respect. I
    
haven't followed the thread well enough to have an o=
pinion if RPL
      
should do
    
that.

Routers will also find other features of 6lowpan-nd-09 useful, for
      
example
    
during initial bootstrapping, to maintain their defa=
ult router and
      
neighbor
    
caches, avoid the need for address resolution, and t=
o perform NUD. The=20
draft (tries to) clearly state when features are required or optional
      
for a
    
router.

Zach


      
From: Michael Richardson <mcr@sandelman.ca>=

Date: Tue, 27 Apr 2010 10:38:47 -0400

          
"Richard" =3D=3D Richard Kelsey <=
;richard.kelsey@ember.com>
                    
writes:
    
Date: Tue, 27 Apr 2010 14:18:32 +0200 From: =
"Pascal Thubert
(pthubert)" <pthubert@cisco.com>

The question here is that the authoritative routers need to
disseminate the PIO (and the RIO) to all routers in the
              
subnet.
    
   Richard> How do other routing protocols (OSPF, IS-IS, AODV,
          
OLSR)
    
I can only speak for OSPF and ISIS.
Neither deal with multi-hop subnets or with any kind of address=20
assignment.
          
Why should RPL be any different?  Yes, it will be run on multi-hop=20
subnets, but I still do not see how this affects the routing.

        
Both were written when multicast was very new.
          
I am not sure how RPL's handling of multicast matters here.
While RPL is required to route multi-hop multicasts, ND uses=20
link-local multicasts, which do not require routing.

        
Richard> I understand that multi-hop subnets =
are a problem for ND,=20
Richard> but I don't see how the routing protocol is affected.

RPL either requires 6lowpan, or it doesn't.
          
RPL should work fine with ordinary ND.  Why would it require
        
6lowpan?
    
        
If it doesn't, then it has to provide for ND to =
work, or for
          
another
    
protocol to replace it.
          
ND works fine, using link-local, one-hop multicasts.  RPL need not
        
be
    
involved.

If someone wants to run RPL on a node that uses neither ordinary ND
        
or
    
6lowpan's version, then they will need some third =
variety of ND.  I
        
do
    
not see why this is an issue for RPL to address.  =
It seems quite out=20
of scope.

                             -Richard Kelsey=20
_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll

        

_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll
      
_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
6lowpan mailing list
6l=
owpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
--------------010702070003070808080307-- --------------ms060703010907010107090905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MDYxNzM4MDlaMCMGCSqGSIb3DQEJBDEWBBR/tl+FF4l5JDi9IZKSBSf4JNo9VzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBALYz/v1VKEi0ipmO2aiW2Uffh+FW9xzeneL2vsasYI0Fx3t0P2GQSuWFdK8OL/4t6pk0 IiyVQ1XpzTivYRAC+93IGPWbN8OMYgJ1PWA0u4O3dLiPxLbi72FPDzIbxKI98o3tkZ+oF4be HYEHgXre3RMV9J6RNcMceP4334WpLh6RoUQxPnv6rcIOfSLlxqh6wfHVkyMGZUJOy7sBN6/R JAol2W6/GSybbAK05ACwbuzjwW8h0x08coezQyOmAHGocBMhQacabalzhv2NbJLuByF3U2hl Qzp49lDNPI92n3vKC7gO3ohqi5pJ3rYEUn1HmhJDIl0WSyjYJpnbmy0tzFcAAAAAAAA= --------------ms060703010907010107090905-- From robert.cragie@gridmerge.com Thu May 6 10:49:28 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49C2028C18B; Thu, 6 May 2010 10:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdzyQTsB-y4C; Thu, 6 May 2010 10:49:27 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 8E75E28C1A3; Thu, 6 May 2010 10:49:16 -0700 (PDT) Received: from [12.188.45.3] (helo=[198.19.179.250]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OA5Bs-0007Sp-KN; Thu, 06 May 2010 18:48:58 +0100 Message-ID: <4BE300E6.2020703@gridmerge.com> Date: Thu, 06 May 2010 18:48:22 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Richard Kelsey References: <7069.1272031181@marajade.sandelman.ca><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> <87zl0dz0m9.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87zl0dz0m9.fsf@kelsey-ws.hq.ember.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000504070708050300070808" Cc: zach.shelby@sensinode.com, roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 17:49:28 -0000 This is a cryptographically signed message in MIME format. --------------ms000504070708050300070808 Content-Type: multipart/alternative; boundary="------------020205050507050802000309" This is a multi-part message in MIME format. --------------020205050507050802000309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +1 Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 06/05/2010 1:16 PM, Richard Kelsey wrote: >> Date: Thu, 6 May 2010 09:02:28 +0200 >> From: "Pascal Thubert (pthubert)" >> >> [Pascal] 6LoWPAN ND needs some addition to enable RPL aware hosts. In >> particular around instance IDs. >> =20 > Pascal, I disagree with "needs". The ability to select an > instance ID for a particular message is an optional extra. > RPL works fine without it. I am okay with limiting instance > ID selection to routers. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > =20 --------------020205050507050802000309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com


On 06/05/2010 1:16 PM, Richard Kelsey wrote: 
Date: Thu, 6 May 2010 09:02:28 +0200
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>

[Pascal] 6LoWPAN ND needs some addition to enable RPL aware hosts. In
particular around instance IDs.=20
    
Pascal, I disagree with "needs".  The ability to select an
instance ID for a particular message is an optional extra.
RPL works fine without it.  I am okay with limiting instance
ID selection to routers.

                                 -Richard Kelsey
_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------020205050507050802000309-- --------------ms000504070708050300070808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MDYxNzQ4MjJaMCMGCSqGSIb3DQEJBDEWBBQ9Eq7Erqm+VHwB4l2yzaYvKO2ehjBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBABzbWy719FaTxb44LQukqumb0aM+ny/3FyjckLAUMk4qG7Me1eMMZR7CNIrleMtdIy2I N0dRk91b+S+BqjiWEltbGPmeHPfdEs/9cxuVj+6NMk2Tg43XaoNZZZlacXEKOf5lM5l+Om7J V+9txBF8XBy7ShHUyOSeqFmuhBWUnV4zWHNOAOjInWTpFWaZrXeAPweT/ETE4xawMv1amjxb 3ieoExnFbgGp5DiHFZybHV5HLVW9VxvGpGQTJHjUag5IzykJ2U07dUnVHIMUOBzLnBEeiKDU sdJ+LQ8J4OsGk/8nPARd/oOTp3X2+aBqFk0RQuDmYVHkcMwBoTgC2fRlm6YAAAAAAAA= --------------ms000504070708050300070808-- From robert.cragie@gridmerge.com Thu May 6 10:49:36 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 845DD3A68AC; Thu, 6 May 2010 10:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZSQZ9OiTS3H; Thu, 6 May 2010 10:49:35 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 519C128C1A1; Thu, 6 May 2010 10:49:26 -0700 (PDT) Received: from [12.188.45.3] (helo=[198.19.179.250]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OA5Bn-00074r-Rl; Thu, 06 May 2010 18:49:08 +0100 Message-ID: <4BE300C2.4080309@gridmerge.com> Date: Thu, 06 May 2010 18:47:46 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Anders Brandt References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi><6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> <675EB7B8-FA26-4C9 9-85AE-E CEEF22F8FF0@tzi.org> <6D9687E95918C04A8B30A7D6DA805A3E0142A10E@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A10E@zensys17.zensys.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060308040103080209050805" Cc: Carsten Bormann , ROLL WG , 6lowpan@ietf.org, zach.shelby@sensinode.com Subject: Re: [6lowpan] [Roll] how does a node get an IPaddress X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 17:49:36 -0000 This is a cryptographically signed message in MIME format. --------------ms060308040103080209050805 Content-Type: multipart/alternative; boundary="------------060708050308080107060701" This is a multi-part message in MIME format. --------------060708050308080107060701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Anders, Totally agree. From a bootstrapping point of view, in my mind there is=20 no distinction between host and router. You could argue that if a=20 network is formed dynamically, natural RA propagation in the forming=20 tree structure might be enough if the first node is the ABR. However, I=20 think there also needs to be a mechanism to propagate options throughout = the network generally. For this piece, and I stress this piece *only*, I = believe that ND is probably not the right place to specify this. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 06/05/2010 9:49 AM, Anders Brandt wrote: > Let me try one more time: > > How much of this will I have to implement to be compliant with other > LLN/RPL nodes? > > In a home control/building environment, the notion of a router nodes is= > rather artificial. > > I may have _host_nodes_. They are host nodes because they are sleeping > (battery operated) > and therefore they cannot participate in routing. > They still have to get an IP address to talk to other IP hosts. > > Alternatively, I may have combined _host&router_nodes_ which serve a > purpose application-wise > and at the same time happen to be routing resources. > Do these hosts have to use another way of getting IP addresses just > because they happen to > be able to do routing? > > > From a designer's standpoint it does not seem quite elegant that I ha= ve > to do use different > methods depending on the power model for my node. Am I missing somethin= g > here? > > Thanks, > Anders > > =20 >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org >> [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann >> Sent: Thursday, May 06, 2010 10:04 >> To: Pascal Thubert (pthubert) >> Cc: ROLL WG; zach.shelby@sensinode.com; 6lowpan@ietf.org >> Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a >> node get an IPaddress) >> >> On May 6, 2010, at 09:02, Pascal Thubert (pthubert) wrote: >> >> =20 >>> enable RPL aware hosts >>> =20 >> Should we? >> >> (Obviously, if a node really needs to know about RPL, it can >> always become a router.) >> >> If I understand you correctly, this is about hosts selecting >> a specific RPL instance-ID for outgoing traffic. >> Traditionally, IP has used the TOS byte (Traffic Class in >> IPv6) to select between different behaviors of the forwarding >> system. What is it that the host wants to say by selecting a >> specific RPL instance ID? Why can't the router make that >> selection, e.g. based on the Traffic Class and the >> destination address? >> >> (Another interesting question is, for incoming traffic, how a >> host selects which instances it wants to be part of. Is that >> even a useful thing to do? Would that selection be made by >> the host, by its first-hop router, or by some configuration agent?) >> >> It would be useful to get more information about how >> instance-IDs are intended to be used with RPL. >> >> On the protocol side: >> If there really is something that a host needs to know about >> RPL-specific information (instances or whatever), this could >> be delivered in an ND option that could very well be defined >> in an RPL-related document, no need to define it in >> 6LoWPAN-ND. Another way to set up this information would be >> to configure it during commissioning or using a host >> configuration protocol like DHCP. >> >> Gruesse, Carsten >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> =20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > =20 --------------060708050308080107060701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Anders,

Totally agree. From a bootstrapping point of view, in my mind there is no distinction between host and router. You could argue that if a network is formed dynamically, natural RA propagation in the forming tree structure might be enough if the first node is the ABR. However, I think there also needs to be a mechanism to propagate options throughout the network generally. For this piece, and I stress this piece *only*, I believe that ND is probably not the right place to specify this.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com


On 06/05/2010 9:49 AM, Anders Brandt wrote: 
Let me try one more time:

How much of this will I have to implement to be compliant with other
LLN/RPL nodes?

In a home control/building environment, the notion of a router nodes is
rather artificial.

I may have _host_nodes_. They are host nodes because they are sleeping
(battery operated)
and therefore they cannot participate in routing.
They still have to get an IP address to talk to other IP hosts.

Alternatively, I may have combined _host&router_nodes_ which serve a
purpose application-wise
and at the same time happen to be routing resources.
Do these hosts have to use another way of getting IP addresses just
because they happen to
be able to do routing?

>From a designer's standpoint it does not seem quite elegant that I ha=
ve
to do use different
methods depending on the power model for my node. Am I missing something
here?

Thanks,
  Anders

  
-----Original Message-----
From: 6lowpan-bounces@ietf.org=20
[mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann
Sent: Thursday, May 06, 2010 10:04
To: Pascal Thubert (pthubert)
Cc: ROLL WG; zach.shelby@sensinode.com; 6lowpan@ietf.org
Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a=20
node get an IPaddress)

On May 6, 2010, at 09:02, Pascal Thubert (pthubert) wrote:

    
enable RPL aware hosts
      
Should we?

(Obviously, if a node really needs to know about RPL, it can=20
always become a router.)

If I understand you correctly, this is about hosts selecting=20
a specific RPL instance-ID for outgoing traffic.
Traditionally, IP has used the TOS byte (Traffic Class in=20
IPv6) to select between different behaviors of the forwarding=20
system.  What is it that the host wants to say by selecting a=20
specific RPL instance ID?  Why can't the router make that=20
selection, e.g. based on the Traffic Class and the=20
destination address?

(Another interesting question is, for incoming traffic, how a=20
host selects which instances it wants to be part of.  Is that=20
even a useful thing to do?  Would that selection be made by=20
the host, by its first-hop router, or by some configuration agent?)

It would be useful to get more information about how=20
instance-IDs are intended to be used with RPL.

On the protocol side:
If there really is something that a host needs to know about=20
RPL-specific information (instances or whatever), this could=20
be delivered in an ND option that could very well be defined=20
in an RPL-related document, no need to define it in=20
6LoWPAN-ND.  Another way to set up this information would be=20
to configure it during commissioning or using a host=20
configuration protocol like DHCP.

Gruesse, Carsten

_______________________________________________
6lowpan mailing list
6l=
owpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan

    
_______________________________________________
6lowpan mailing list
6l=
owpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
--------------060708050308080107060701-- --------------ms060308040103080209050805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MDYxNzQ3NDZaMCMGCSqGSIb3DQEJBDEWBBTyR5+ezh/QetZ0MzGeHzQ6J6WvbDBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAAmX7bVS11km0rNJSEVJNwQ5MeoINUF1Np6hcffUE/94tKK2SSus9Q1AA/WNkkDgd25S Jb4xYZO+yaaH60FOG3MvvK394MA37u6eu+/q57ZSLepvUVcLuHixvO9un5WFJ/phBOiDnBIy 45fAy5OpIFYUR19zsUa75K/o5G/QkTYpn0Y41ZvOxOpCuOyFzmx6+hjPJ7cSrC94+Ak20MbO LT4DfP82GXBcmmC8q2bIvdzY9Si4nFC1CJjHcFAko3ICDNj7Vz2nXKxtgjBj41Bq06/6xBEm SVe5fuYinzXNDANfE838fV4ow7aB3lCvy9Ni089JonnXM3bGLKG+8VtrsgkAAAAAAAA= --------------ms060308040103080209050805-- From cabo@tzi.org Thu May 6 10:55:44 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E973A68C0; Thu, 6 May 2010 10:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.819 X-Spam-Level: X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23JvHr+xuQc6; Thu, 6 May 2010 10:55:43 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 6799D3A695F; Thu, 6 May 2010 10:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o46HtF5L014872; Thu, 6 May 2010 19:55:15 +0200 (CEST) Received: from [192.168.217.101] (p5489BAFC.dip.t-dialin.net [84.137.186.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 46374D89F; Thu, 6 May 2010 19:55:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <87zl0dz0m9.fsf@kelsey-ws.hq.ember.com> Date: Thu, 6 May 2010 19:55:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <30EFF517-644E-4E8E-AEF4-21F5CB54AD81@tzi.org> References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> <87zl0dz0m9. fsf@kelsey-ws.hq.ember.com> To: ROLL WG , 6lowpan@ietf.org X-Mailer: Apple Mail (2.1078) Subject: [6lowpan] So do we need instance ID selection in hosts? (Re: [Roll] how does a node get an IP address) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 06 May 2010 17:55:44 -0000 On May 6, 2010, at 14:16, Richard Kelsey wrote: >> Date: Thu, 6 May 2010 09:02:28 +0200 >> From: "Pascal Thubert (pthubert)" >>=20 >> [Pascal] 6LoWPAN ND needs some addition to enable RPL aware hosts. In >> particular around instance IDs.=20 >=20 > Pascal, I disagree with "needs". The ability to select an > instance ID for a particular message is an optional extra. > RPL works fine without it. I am okay with limiting instance > ID selection to routers. Richard, this is very useful input. Thank you. (And thank you for the +1, Robert.) Now the next step is to find out whether there is consensus on this = point. Those of you who have an idea what you want to use multiple RPL = instances for: Would you be happy with limiting support for instance selection to = routers? Gruesse, Carsten From zach@sensinode.com Thu May 6 11:45:09 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2596C28C0E6 for <6lowpan@core3.amsl.com>; Thu, 6 May 2010 11:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCDamyEk4rpd for <6lowpan@core3.amsl.com>; Thu, 6 May 2010 11:45:07 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 0008B3A6B59 for <6lowpan@ietf.org>; Thu, 6 May 2010 11:45:03 -0700 (PDT) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o46Iih9t021201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 May 2010 21:44:44 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: <4BE2FE81.5040600@gridmerge.com> Date: Thu, 6 May 2010 21:44:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <4BE2FE81.5040600@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1077) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 06 May 2010 18:45:09 -0000 (limited to the 6lowpan mailing list) On May 6, 2010, at 20:38 , Robert Cragie wrote: > Hi Zach, >=20 > I agree with some of what you say but not all of it. See inline = comments. In a nutshell: > =95 We need ND for bootstrapping hosts and routers and to = maintain hosts. I think nd-09 supports this well > =95 Hosts do not need to know anything about routing protocol = used in the wider network > =95 There is nothing wrong with using RPL's (or any other = routing protocol) implicit multicast mechanism for disseminating lowpan = wide information Exactly, well summarized. Now regarding one point below: > Robert > Robert Cragie (Pacific Gas & Electric) >=20 > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com >=20 >=20 > On 05/05/2010 4:42 PM, Zach Shelby wrote: >> Hi, >>=20 >> On May 5, 2010, at 17:18 , Mathilde Durvy (mdurvy) wrote: >>=20 >> =20 >>=20 >>> Hi Pascal, >>>=20 >>> I fully agree with you. >>> In my opinion anything spanning multiple IP hops should not be done = by ND. >>> =20 >>>=20 >> That logic doesn't work anymore with route-over LoWPANs. As the = prefixes are spanning the whole LoWPAN there is a natural need for ND to = help with that. > (1) I repeat - classic ND has no concept over this, so there = isn't a natural need for ND to help with this. There has been a choice = to add in a mechanism but that mechanism is a 'multicast' mechanism = which implicitly has to define propagation. Propagation is not the = domain of ND but is the domain of the associated routing protocol Here is the critical difference. IPv6 has no concept of a prefix being = used multihop across multiple routers in the same subnet, which is why = RFC4861 never dealt with it. A route-over LoWPAN is special in the way = that the same prefix and context information needs to be synchronized = multihop. This is not the case with IPv6 where you instead do prefix = delegation to routers, thus each router advertises a different prefix.=20= As this flat prefix propagation is special to 6LoWPAN, it is really a = 6LoWPAN problem. This is the reason why an optional solution for it = simply using RS/RA is included in nd-09 (and in most previous versions = of nd as well).=20 Now, as we all seem to agree, a routing protocol could handle the task = of getting prefix and context information to 6LRs... but then it needs = something pretty 6LoWPAN specific there... General routing protocols = designed for IPv6 (DYMO, AODV etc.) won't do this for you, thus in that = case 6lowpan-nd has a mechanism that can be used.=20 The challenge in ROLL would be how to support both IPv6 prefix = delegation and 6LoWPAN prefix/context dissemination without being = 6LoWPAN specific? That will be the real issue to discuss on the ROLL = mailing list I guess. Zach --=20 Zach Shelby, Head of Research, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From pister@eecs.berkeley.edu Thu May 6 14:27:53 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8351E3A6A40; Thu, 6 May 2010 14:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.134 X-Spam-Level: X-Spam-Status: No, score=-5.134 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OzHEg-YxJOe; Thu, 6 May 2010 14:27:52 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 57DE63A67B3; Thu, 6 May 2010 14:27:15 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o46LR0wx024626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 May 2010 14:27:01 -0700 (PDT) Message-ID: <4BE33425.9090006@eecs.berkeley.edu> Date: Thu, 06 May 2010 14:27:01 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Anders Brandt References: <7069.1272031181@marajade.sandelman.ca> <4BD58ED9.8070401@gridmerge.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local> <4BD59F27.1020208@gridmerge.com> <0a9b01cae5a3$79d6a320$6d83e960$@com> <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com> <87d3xl0zmn.fsf@kelsey-ws.hq.ember.com> <11301.1272379127@marajade.sandelman.ca> <87bpd429wp.fsf@kelsey-ws.hq.ember.com> <49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> <"675EB7B8-FA26-4C9 9-85AE-E CEEF22F8FF0"@tzi.org> <6D9687E95918C04A8B30A7D6DA805A3E0142A10E@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A10E@zensys17.zensys.local> Content-Type: multipart/alternative; boundary="------------030202020002080105060403" Cc: ROLL WG , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IPaddress X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 06 May 2010 21:27:53 -0000 This is a multi-part message in MIME format. --------------030202020002080105060403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Anders - there are many commercial networks (even in buildings and homes) where battery operated nodes are routers. I don't think that we should confuse the line/battery power issue with the host/router issue. There are many reasons why a node might choose or be designated to be a host not a router, so your question still stands. But it's not a power issue. ksjp Anders Brandt wrote: > Let me try one more time: > > How much of this will I have to implement to be compliant with other > LLN/RPL nodes? > > In a home control/building environment, the notion of a router nodes is > rather artificial. > > I may have _host_nodes_. They are host nodes because they are sleeping > (battery operated) > and therefore they cannot participate in routing. > They still have to get an IP address to talk to other IP hosts. > > Alternatively, I may have combined _host&router_nodes_ which serve a > purpose application-wise > and at the same time happen to be routing resources. > Do these hosts have to use another way of getting IP addresses just > because they happen to > be able to do routing? > > From a designer's standpoint it does not seem quite elegant that I have > to do use different > methods depending on the power model for my node. Am I missing something > here? > > Thanks, > Anders > > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org >> [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann >> Sent: Thursday, May 06, 2010 10:04 >> To: Pascal Thubert (pthubert) >> Cc: ROLL WG; zach.shelby@sensinode.com; 6lowpan@ietf.org >> Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a >> node get an IPaddress) >> >> On May 6, 2010, at 09:02, Pascal Thubert (pthubert) wrote: >> >> >>> enable RPL aware hosts >>> >> Should we? >> >> (Obviously, if a node really needs to know about RPL, it can >> always become a router.) >> >> If I understand you correctly, this is about hosts selecting >> a specific RPL instance-ID for outgoing traffic. >> Traditionally, IP has used the TOS byte (Traffic Class in >> IPv6) to select between different behaviors of the forwarding >> system. What is it that the host wants to say by selecting a >> specific RPL instance ID? Why can't the router make that >> selection, e.g. based on the Traffic Class and the >> destination address? >> >> (Another interesting question is, for incoming traffic, how a >> host selects which instances it wants to be part of. Is that >> even a useful thing to do? Would that selection be made by >> the host, by its first-hop router, or by some configuration agent?) >> >> It would be useful to get more information about how >> instance-IDs are intended to be used with RPL. >> >> On the protocol side: >> If there really is something that a host needs to know about >> RPL-specific information (instances or whatever), this could >> be delivered in an ND option that could very well be defined >> in an RPL-related document, no need to define it in >> 6LoWPAN-ND. Another way to set up this information would be >> to configure it during commissioning or using a host >> configuration protocol like DHCP. >> >> Gruesse, Carsten >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------030202020002080105060403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Anders - there are many commercial networks (even in buildings and homes) where battery operated nodes are routers.  I don't think that we should confuse the line/battery power issue with the host/router issue.
There are many reasons why a node might choose or be designated to be a host not a router, so your question still stands.  But it's not a power issue.

ksjp

Anders Brandt wrote: 
Let me try one more time:

How much of this will I have to implement to be compliant with other
LLN/RPL nodes?

In a home control/building environment, the notion of a router nodes is
rather artificial.

I may have _host_nodes_. They are host nodes because they are sleeping
(battery operated)
and therefore they cannot participate in routing.
They still have to get an IP address to talk to other IP hosts.

Alternatively, I may have combined _host&router_nodes_ which serve a
purpose application-wise
and at the same time happen to be routing resources.
Do these hosts have to use another way of getting IP addresses just
because they happen to
be able to do routing?

>From a designer's standpoint it does not seem quite elegant that I have
to do use different
methods depending on the power model for my node. Am I missing something
here?

Thanks,
  Anders

  
-----Original Message-----
From: 6lowpan-bounces@ietf.org 
[mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann
Sent: Thursday, May 06, 2010 10:04
To: Pascal Thubert (pthubert)
Cc: ROLL WG; zach.shelby@sensinode.com; 6lowpan@ietf.org
Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a 
node get an IPaddress)

On May 6, 2010, at 09:02, Pascal Thubert (pthubert) wrote:

    
enable RPL aware hosts
      
Should we?

(Obviously, if a node really needs to know about RPL, it can 
always become a router.)

If I understand you correctly, this is about hosts selecting 
a specific RPL instance-ID for outgoing traffic.
Traditionally, IP has used the TOS byte (Traffic Class in 
IPv6) to select between different behaviors of the forwarding 
system.  What is it that the host wants to say by selecting a 
specific RPL instance ID?  Why can't the router make that 
selection, e.g. based on the Traffic Class and the 
destination address?

(Another interesting question is, for incoming traffic, how a 
host selects which instances it wants to be part of.  Is that 
even a useful thing to do?  Would that selection be made by 
the host, by its first-hop router, or by some configuration agent?)

It would be useful to get more information about how 
instance-IDs are intended to be used with RPL.

On the protocol side:
If there really is something that a host needs to know about 
RPL-specific information (instances or whatever), this could 
be delivered in an ND option that could very well be defined 
in an RPL-related document, no need to define it in 
6LoWPAN-ND.  Another way to set up this information would be 
to configure it during commissioning or using a host 
configuration protocol like DHCP.

Gruesse, Carsten

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

    
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------030202020002080105060403-- From pthubert@cisco.com Thu May 6 23:09:44 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3EC3A6BC0; Thu, 6 May 2010 23:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.884 X-Spam-Level: X-Spam-Status: No, score=-8.884 tagged_above=-999 required=5 tests=[AWL=1.714, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95+3BO2-81-2; Thu, 6 May 2010 23:09:40 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 14F973A6BBB; Thu, 6 May 2010 23:08:28 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAJdL40urR7Ht/2dsb2JhbACBPpxPcaFpmUyFFQQ X-IronPort-AV: E=Sophos;i="4.52,346,1270425600"; d="scan'208,217";a="193865987" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 07 May 2010 06:08:15 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4768CCZ009260; Fri, 7 May 2010 06:08:14 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 08:08:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAEDAB.AD5360E5" Date: Fri, 7 May 2010 08:08:10 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01D605A8@XMB-AMS-107.cisco.com> In-Reply-To: <4BE300E6.2020703@gridmerge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [6lowpan] how does a node get an IP address Thread-Index: AcrtRHpJBCkKomw4QqCDqkNKzNMvIAAZLHUQ References: <7069.1272031181@marajade.sandelman.ca><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> <87zl0dz0m9.fsf@kelsey-ws.hq.ember.com> <4BE300E6.2020703@gridmerge.com> From: "Pascal Thubert (pthubert)" To: , "Richard Kelsey" X-OriginalArrivalTime: 07 May 2010 06:08:14.0135 (UTC) FILETIME=[AD9BF470:01CAEDAB] Cc: roll@ietf.org, zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 07 May 2010 06:09:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAEDAB.AD5360E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert and Richard: =20 We designed instances to enable to support multiple sorts of traffic with different requirements. =20 The instance is the network response to the application needs. The application resides in the host, even if routers sometimes play both roles. The application needs to signal the instance one way or another in its packets, and we use flow labels for that. So far so good.=20 =20 What's missing: =20 - The host also needs to join the RPL networks that support the instances that it needs. That must be signaled in the router to host interface. - The host also needs to be advertised in the RPL networks that support the instances that it needs. That must be signaled in the host to router interface. =20 >From there I think you've got the logic reverse: You're correct that ROLL supports a host with no RPL extension using instance 0 / flow label 0. But still the host to router interface needs to be augmented for an application residing on the host to benefit from ROLL instances.=20 =20 What I'm reading below is "a host MUST be a router in order to comply with the ROLL MUST of supporting multiple types of traffic". =20 Well, -1. =20 Pascal =20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: Thursday, May 06, 2010 7:48 PM To: Richard Kelsey Cc: Pascal Thubert (pthubert); zach.shelby@sensinode.com; roll@ietf.org; 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IP address =20 +1 Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 On 06/05/2010 1:16 PM, Richard Kelsey wrote:=20 Date: Thu, 6 May 2010 09:02:28 +0200 From: "Pascal Thubert (pthubert)" =20 =20 [Pascal] 6LoWPAN ND needs some addition to enable RPL aware hosts. In particular around instance IDs.=20 =20 =20 Pascal, I disagree with "needs". The ability to select an instance ID for a particular message is an optional extra. RPL works fine without it. I am okay with limiting instance ID selection to routers. =20 -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 =20 ------_=_NextPart_001_01CAEDAB.AD5360E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert and Richard:

 

We designed instances to enable to support multiple sorts of traffic = with different requirements.

 

The instance is the network response to the application needs. The = application resides in the host, even if routers sometimes play both = roles.

The application needs to signal the instance one way or another in = its packets, and we use flow labels for that. So far so good. =

 

What’s missing:

 

-          = The host also needs to join the RPL networks that support the = instances that it needs. That must be signaled in the router to host = interface.

-          = The host also needs to be advertised in the RPL networks that support = the instances that it needs. That must be signaled in the host to router = interface.

 

From there I think you’ve got the logic = reverse:

You’re correct that ROLL supports a host with no RPL extension = using instance 0 / flow label 0.

But still the host to router interface needs to be augmented for an = application residing on the host to benefit from ROLL instances. =

 

What I’m reading below is “a host MUST be a router in = order to comply with the ROLL MUST of supporting multiple types of = traffic”.

 

Well, -1.

 

Pascal

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com] =
Sent: Thursday, May 06, 2010 7:48 PM
To: Richard = Kelsey
Cc: Pascal Thubert (pthubert); = zach.shelby@sensinode.com; roll@ietf.org; = 6lowpan@ietf.org
Subject: Re: [Roll] [6lowpan] how does a node = get an IP address

 

+1

Robert Cragie = (Pacific Gas & Electric)

Gridmerge Ltd.
89 = Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 = 910888
http://www.gridmerge.com


On 06/05/2010 1:16 PM, Richard = Kelsey wrote: 

Date: Thu, 6 May =
2010 09:02:28 +0200
From: "Pascal Thubert =
(pthubert)" <pthubert@cisco.com>
 
[Pascal] 6LoWPAN ND needs some =
addition to enable RPL aware hosts. In
particular =
around instance IDs. =

    
 
Pascal, I disagree with =
"needs".  The ability to select =
an
instance ID for a particular message is an =
optional extra.
RPL works fine without it.  I =
am okay with limiting instance
ID selection to =
routers.
 
  &nb=
sp;           &nbs=
p;            =
;      -Richard =
Kelsey
_____________________________________________=
__
Roll mailing list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll
 
 
------_=_NextPart_001_01CAEDAB.AD5360E5-- From abr@sdesigns.dk Fri May 7 00:02:45 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE8693A6B9E; Fri, 7 May 2010 00:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1wiVS0AaM11; Fri, 7 May 2010 00:02:44 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id EB1B53A6C28; Fri, 7 May 2010 00:02:43 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAEDB3.42A1102A" Date: Fri, 7 May 2010 09:02:30 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A116@zensys17.zensys.local> In-Reply-To: <4BE33425.9090006@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [6lowpan] how does a node get an IPaddress Thread-Index: AcrtYt/xrKwKisYIQFydu1CPNQBzFwAUCUEA References: <7069.1272031181@marajade.sandelman.ca> <4BD58ED9.8070401@gridmerge.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local> <4BD59F27.1020208@gridmerge.com> <0a9b01cae5a3$79d6a320$6d83e960$@com> <6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com> <87d3xl0zmn.fsf@kelsey-ws.hq.ember.com> <11301.1272379127@marajade.sandelman.ca> <87bpd429wp.fsf@kelsey-ws.hq.ember.com> <49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> <"675EB7B8-FA26-4C9 9-85AE-E CEEF22F8FF0"@tzi.org> <6D9687E95918C04A8B30A7D6DA805A3E0142A10E@zensys17.zensys.local> <4BE33425.9090006@eecs.berkeley.edu> From: "Anders Brandt" To: "Kris Pister" Cc: ROLL WG , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IPaddress X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 07 May 2010 07:02:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAEDB3.42A1102A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kris, =20 > But it's not a power issue =20 Agreed. This was meant to be an example only ;-) =20 - Anders =20 =20 ________________________________ From: Kris Pister [mailto:pister@eecs.berkeley.edu]=20 Sent: Thursday, May 06, 2010 23:27 To: Anders Brandt Cc: ROLL WG; 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IPaddress =09 =09 Anders - there are many commercial networks (even in buildings and homes) where battery operated nodes are routers. I don't think that we should confuse the line/battery power issue with the host/router issue. There are many reasons why a node might choose or be designated to be a host not a router, so your question still stands. But it's not a power issue. =09 ksjp =09 Anders Brandt wrote:=20 Let me try one more time: =09 How much of this will I have to implement to be compliant with other LLN/RPL nodes? =09 In a home control/building environment, the notion of a router nodes is rather artificial. =09 I may have _host_nodes_. They are host nodes because they are sleeping (battery operated) and therefore they cannot participate in routing. They still have to get an IP address to talk to other IP hosts. =09 Alternatively, I may have combined _host&router_nodes_ which serve a purpose application-wise and at the same time happen to be routing resources. Do these hosts have to use another way of getting IP addresses just because they happen to be able to do routing? =09 From a designer's standpoint it does not seem quite elegant that I have to do use different methods depending on the power model for my node. Am I missing something here? =09 Thanks, Anders =09 =20 -----Original Message----- From: 6lowpan-bounces@ietf.org=20 [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Thursday, May 06, 2010 10:04 To: Pascal Thubert (pthubert) Cc: ROLL WG; zach.shelby@sensinode.com; 6lowpan@ietf.org Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a=20 node get an IPaddress) =09 On May 6, 2010, at 09:02, Pascal Thubert (pthubert) wrote: =09 =20 enable RPL aware hosts =20 Should we? =09 (Obviously, if a node really needs to know about RPL, it can=20 always become a router.) =09 If I understand you correctly, this is about hosts selecting=20 a specific RPL instance-ID for outgoing traffic. Traditionally, IP has used the TOS byte (Traffic Class in=20 IPv6) to select between different behaviors of the forwarding=20 system. What is it that the host wants to say by selecting a=20 specific RPL instance ID? Why can't the router make that=20 selection, e.g. based on the Traffic Class and the=20 destination address? =09 (Another interesting question is, for incoming traffic, how a=20 host selects which instances it wants to be part of. Is that=20 even a useful thing to do? Would that selection be made by=20 the host, by its first-hop router, or by some configuration agent?) =09 It would be useful to get more information about how=20 instance-IDs are intended to be used with RPL. =09 On the protocol side: If there really is something that a host needs to know about=20 RPL-specific information (instances or whatever), this could=20 be delivered in an ND option that could very well be defined=20 in an RPL-related document, no need to define it in=20 6LoWPAN-ND. Another way to set up this information would be=20 to configure it during commissioning or using a host=20 configuration protocol like DHCP. =09 Gruesse, Carsten =09 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan =09 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CAEDB3.42A1102A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Kris,
 
> But=20 it's not a power issue
 
Agreed. This was meant to be an example = only=20 ;-)
 
- Anders
 
 

From: Kris Pister=20 [mailto:pister@eecs.berkeley.edu]
Sent: Thursday, May 06, = 2010=20 23:27
To: Anders Brandt
Cc: ROLL WG;=20 6lowpan@ietf.org
Subject: Re: [Roll] [6lowpan] how does a = node get=20 an IPaddress

Anders - there are many commercial networks (even in = buildings and=20 homes) where battery operated nodes are routers.  I don't think = that we=20 should confuse the line/battery power issue with the host/router=20 issue.
There are many reasons why a node might choose or be = designated to=20 be a host not a router, so your question still stands.  But it's = not a=20 power issue.

ksjp

Anders Brandt wrote:=20 
Let me try one more time:

How much of this will I have to implement to be compliant with other
LLN/RPL nodes?

In a home control/building environment, the notion of a router nodes is
rather artificial.

I may have _host_nodes_. They are host nodes because they are sleeping
(battery operated)
and therefore they cannot participate in routing.
They still have to get an IP address to talk to other IP hosts.

Alternatively, I may have combined _host&router_nodes_ which serve a
purpose application-wise
and at the same time happen to be routing resources.
Do these hosts have to use another way of getting IP addresses just
because they happen to
be able to do routing?

>From a designer's standpoint it does not seem quite elegant that I have
to do use different
methods depending on the power model for my node. Am I missing something
here?

Thanks,
  Anders

  
-----Original Message-----
From: 6lowpan-bounces@ietf.org=20
[mailto:6lowpan-bounces@ietf.org<=
/A>] On Behalf Of Carsten Bormann
Sent: Thursday, May 06, 2010 10:04
To: Pascal Thubert (pthubert)
Cc: ROLL WG; zach.shelby@sensinode.com; =
6lowpan@ietf.org
Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a=20
node get an IPaddress)

On May 6, 2010, at 09:02, Pascal Thubert (pthubert) wrote:

    
enable RPL aware hosts
      
Should we?

(Obviously, if a node really needs to know about RPL, it can=20
always become a router.)

If I understand you correctly, this is about hosts selecting=20
a specific RPL instance-ID for outgoing traffic.
Traditionally, IP has used the TOS byte (Traffic Class in=20
IPv6) to select between different behaviors of the forwarding=20
system.  What is it that the host wants to say by selecting a=20
specific RPL instance ID?  Why can't the router make that=20
selection, e.g. based on the Traffic Class and the=20
destination address?

(Another interesting question is, for incoming traffic, how a=20
host selects which instances it wants to be part of.  Is that=20
even a useful thing to do?  Would that selection be made by=20
the host, by its first-hop router, or by some configuration agent?)

It would be useful to get more information about how=20
instance-IDs are intended to be used with RPL.

On the protocol side:
If there really is something that a host needs to know about=20
RPL-specific information (instances or whatever), this could=20
be delivered in an ND option that could very well be defined=20
in an RPL-related document, no need to define it in=20
6LoWPAN-ND.  Another way to set up this information would be=20
to configure it during commissioning or using a host=20
configuration protocol like DHCP.

Gruesse, Carsten

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/6lowpan

    
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll
------_=_NextPart_001_01CAEDB3.42A1102A-- From pthubert@cisco.com Fri May 7 05:48:13 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622593A6AD5; Fri, 7 May 2010 05:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.925 X-Spam-Level: X-Spam-Status: No, score=-8.925 tagged_above=-999 required=5 tests=[AWL=1.673, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Kz3oTbVPh2O; Fri, 7 May 2010 05:48:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 963253A69F0; Fri, 7 May 2010 05:48:05 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAGao40urR7H+/2dsb2JhbACBPpxWcaNjmV2FFQSPRg X-IronPort-AV: E=Sophos;i="4.52,348,1270425600"; d="scan'208,217";a="126271100" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 07 May 2010 12:47:51 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o47ClYKu026450; Fri, 7 May 2010 12:47:51 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 14:47:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAEDE3.76C6F173" Date: Fri, 7 May 2010 14:47:27 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01D60847@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IPaddress Thread-Index: Acrt43JYXTd+ERJIS7GecowaH2hV/A== From: "Pascal Thubert (pthubert)" To: "Anders Brandt" , "Kris Pister" X-OriginalArrivalTime: 07 May 2010 12:47:34.0298 (UTC) FILETIME=[76FAAFA0:01CAEDE3] Cc: ROLL WG , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IPaddress X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 07 May 2010 12:48:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAEDE3.76C6F173 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Anders: =20 There are a number of requirement drafts for this and that. =20 I think Julien and Mathilde tried to compile at some point what the arch minimum would be in a device to run IPv6 and looks OK. =20 The recent developments are that people tend to think that you can live with an IPv6 derived from the MAC address without any DAD. =20 But you'd still need the prefix information that's found in the RA-PIO and the routing information that's found in the RA-RIO (that's very much like RPL 08's DPO). =20 So you see, it is actually very useful to RPL routers to carry those RA options unchanged within RPL's DIO =20 Current ND is the de facto abstraction for the host interface. =20 Some LLN/LoWPANs bring in a number of new concepts from route over. And now we're wondering what's the position of ND in that world.=20 =20 At one extreme we could say that the route over piece is a router problem and externalize it from ND unto RPL and such. At the other, we could consider that RPL is actually the component of ND that handles router to router. Why not after all? =20 Cheers, =20 Pascal =20 From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Friday, May 07, 2010 9:03 AM To: Kris Pister Cc: ROLL WG; 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IPaddress =20 Kris, =20 > But it's not a power issue =20 Agreed. This was meant to be an example only ;-) =20 - Anders =20 =20 =20 ________________________________ From: Kris Pister [mailto:pister@eecs.berkeley.edu]=20 Sent: Thursday, May 06, 2010 23:27 To: Anders Brandt Cc: ROLL WG; 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IPaddress Anders - there are many commercial networks (even in buildings and homes) where battery operated nodes are routers. I don't think that we should confuse the line/battery power issue with the host/router issue. There are many reasons why a node might choose or be designated to be a host not a router, so your question still stands. But it's not a power issue. =09 ksjp =09 Anders Brandt wrote:=20 Let me try one more time: =20 How much of this will I have to implement to be compliant with other LLN/RPL nodes? =20 In a home control/building environment, the notion of a router nodes is rather artificial. =20 I may have _host_nodes_. They are host nodes because they are sleeping (battery operated) and therefore they cannot participate in routing. They still have to get an IP address to talk to other IP hosts. =20 Alternatively, I may have combined _host&router_nodes_ which serve a purpose application-wise and at the same time happen to be routing resources. Do these hosts have to use another way of getting IP addresses just because they happen to be able to do routing? =20 From a designer's standpoint it does not seem quite elegant that I have to do use different methods depending on the power model for my node. Am I missing something here? =20 Thanks, Anders =20 =20 -----Original Message----- From: 6lowpan-bounces@ietf.org=20 [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Thursday, May 06, 2010 10:04 To: Pascal Thubert (pthubert) Cc: ROLL WG; zach.shelby@sensinode.com; 6lowpan@ietf.org Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a=20 node get an IPaddress) =20 On May 6, 2010, at 09:02, Pascal Thubert (pthubert) wrote: =20 =20 enable RPL aware hosts =20 Should we? =20 (Obviously, if a node really needs to know about RPL, it can=20 always become a router.) =20 If I understand you correctly, this is about hosts selecting=20 a specific RPL instance-ID for outgoing traffic. Traditionally, IP has used the TOS byte (Traffic Class in=20 IPv6) to select between different behaviors of the forwarding=20 system. What is it that the host wants to say by selecting a=20 specific RPL instance ID? Why can't the router make that=20 selection, e.g. based on the Traffic Class and the=20 destination address? =20 (Another interesting question is, for incoming traffic, how a=20 host selects which instances it wants to be part of. Is that=20 even a useful thing to do? Would that selection be made by=20 the host, by its first-hop router, or by some configuration agent?) =20 It would be useful to get more information about how=20 instance-IDs are intended to be used with RPL. =20 On the protocol side: If there really is something that a host needs to know about=20 RPL-specific information (instances or whatever), this could=20 be delivered in an ND option that could very well be defined=20 in an RPL-related document, no need to define it in=20 6LoWPAN-ND. Another way to set up this information would be=20 to configure it during commissioning or using a host=20 configuration protocol like DHCP. =20 Gruesse, Carsten =20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan =20 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CAEDE3.76C6F173 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Anders:

 

There are a number of requirement drafts for this and = that.

 

I think Julien and Mathilde tried to compile at some point what the = arch minimum would be in a device to run IPv6 and looks = OK.

 

The recent developments are that people tend to think that you can = live with an IPv6 derived from the MAC address without any = DAD.

 

But you’d still need the prefix information that’s found = in the RA-PIO and the routing information that’s found in the = RA-RIO (that’s very much like RPL 08’s = DPO).

 

So you see, it is actually very useful to RPL routers to carry those = RA options unchanged within RPL’s DIO

 

Current ND is the de facto abstraction for the host = interface.

 

Some LLN/LoWPANs bring in a number of new concepts from route over. = And now we’re wondering what’s the position of ND in that = world.

 

At one extreme we could say that the route over piece is a router = problem and externalize it from ND unto RPL and = such.

At the other, we could consider that RPL is actually the component of = ND that handles router to router. Why not after = all?

 

Cheers,

 

Pascal

 

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Anders Brandt
Sent: Friday, May 07, 2010 9:03 = AM
To: Kris Pister
Cc: ROLL WG; = 6lowpan@ietf.org
Subject: Re: [6lowpan] [Roll] how does a node = get an IPaddress

 

Kr= is,

 

&g= t; But it's not a power issue

 

Ag= reed. This was meant to be an example only = ;-)

 

- = Anders

 

 

 

From:= = Kris Pister [mailto:pister@eecs.berkeley.edu]
Sent: Thursday, = May 06, 2010 23:27
To: Anders Brandt
Cc: ROLL WG; = 6lowpan@ietf.org
Subject: Re: [Roll] [6lowpan] how does a node = get an IPaddress

Anders - = there are many commercial networks (even in buildings and homes) where = battery operated nodes are routers.  I don't think that we should = confuse the line/battery power issue with the host/router = issue.
There are many reasons why a node might choose or be = designated to be a host not a router, so your question still = stands.  But it's not a power issue.

ksjp

Anders = Brandt wrote: 

Let me try one more =
time:
 
How much of this =
will I have to implement to be compliant with =
other
LLN/RPL =
nodes?
 
In a home =
control/building environment, the notion of a router nodes =
is
rather =
artificial.
 
I may have =
_host_nodes_. They are host nodes because they are =
sleeping
(battery =
operated)
and therefore they cannot participate in =
routing.
They still have to get an IP address to =
talk to other IP =
hosts.
 
Alternatively, I =
may have combined _host&router_nodes_ which serve =
a
purpose application-wise
and =
at the same time happen to be routing resources.
Do =
these hosts have to use another way of getting IP addresses =
just
because they happen to
be =
able to do =
routing?
 
From a =
designer's standpoint it does not seem quite elegant that I =
have
to do use =
different
methods depending on the power model for =
my node. Am I missing =
something
here?
 
Thanks,
  =
Anders
 
  =

-----Original =
Message-----
From: 6lowpan-bounces@ietf.org =

[mailto:6lowpan-bounces@ietf.org<=
/a>] On Behalf Of Carsten Bormann
Sent: Thursday, =
May 06, 2010 10:04
To: Pascal Thubert =
(pthubert)
Cc: ROLL WG; zach.shelby@sensinode.com; =
6lowpan@ietf.org
Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a = 
node get an =
IPaddress)
 
On May 6, =
2010, at 09:02, Pascal Thubert (pthubert) =
wrote:
 
   =
; 
enable RPL aware =
hosts
 =
     
Should =
we?
 
(Obviously, if a =
node really needs to know about RPL, it can 
always =
become a router.)
 
If I =
understand you correctly, this is about hosts selecting =

a specific RPL instance-ID for outgoing =
traffic.
Traditionally, IP has used the TOS byte =
(Traffic Class in 
IPv6) to select between =
different behaviors of the forwarding =

system.  What is it that the host wants to =
say by selecting a 
specific RPL instance ID?  =
Why can't the router make that 
selection, e.g. =
based on the Traffic Class and the 
destination =
address?
 
(Another =
interesting question is, for incoming traffic, how a =

host selects which instances it wants to be part =
of.  Is that 
even a useful thing to do?  =
Would that selection be made by 
the host, by its =
first-hop router, or by some configuration =
agent?)
 
It would be =
useful to get more information about how =

instance-IDs are intended to be used with =
RPL.
 
On the protocol =
side:
If there really is something that a host =
needs to know about 
RPL-specific information =
(instances or whatever), this could 
be delivered =
in an ND option that could very well be defined 
in =
an RPL-related document, no need to define it in =

6LoWPAN-ND.  Another way to set up this =
information would be 
to configure it during =
commissioning or using a host 
configuration =
protocol like =
DHCP.
 
Gruesse, =
Carsten
 
________________=
_______________________________
6lowpan mailing =
list
6lowpan@ietf.org
https://www.ietf.o= rg/mailman/listinfo/6lowpan
 
    =

______________________________________=
_________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll
  =
------_=_NextPart_001_01CAEDE3.76C6F173-- From abr@sdesigns.dk Fri May 7 05:59:34 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1933A691B; Fri, 7 May 2010 05:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt9oc4DvZLDy; Fri, 7 May 2010 05:59:25 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id D27403A69ED; Fri, 7 May 2010 05:59:24 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAEDE5.168B6FDA" Date: Fri, 7 May 2010 14:59:11 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A120@zensys17.zensys.local> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01D60847@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IPaddress Thread-Index: Acrt43JYXTd+ERJIS7GecowaH2hV/AAAEcVw References: <6A2A459175DABE4BB11DE2026AA50A5D01D60847@XMB-AMS-107.cisco.com> From: "Anders Brandt" To: "Pascal Thubert (pthubert)" Cc: ROLL WG , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IPaddress X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 07 May 2010 12:59:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAEDE5.168B6FDA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pascal, =20 >Current ND is the de facto abstraction for the host interface. .... >At the other, we could consider that RPL is actually the component of ND that handles router to router. Why not after all? =20 I understand that it makes sense in a router perspective to have this stuff in the routing protocol. My problem is that I have to make code for very small nodes. =20 Having two methods I need to support translates into two code blocks I need to include when building code for my nodes. For sure I need a way of assigning addresses to host nodes. This is a hard requirement. RPL assignment seems optional. If I can use the same code in the routing nodes I have more code space for the interesting parts. Don't you agree? =20 >The recent developments are that people tend to think that you can live with an IPv6 derived from the MAC address without any DAD. That is fine with me - but I still need to convey prefix and default gateway, so this really does not change a lot, does it?. =20 Thanks, Anders ________________________________ From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Friday, May 07, 2010 14:47 To: Anders Brandt; Kris Pister Cc: ROLL WG; 6lowpan@ietf.org Subject: RE: [6lowpan] [Roll] how does a node get an IPaddress =09 =09 Hi Anders: =20 There are a number of requirement drafts for this and that. =20 I think Julien and Mathilde tried to compile at some point what the arch minimum would be in a device to run IPv6 and looks OK. =20 The recent developments are that people tend to think that you can live with an IPv6 derived from the MAC address without any DAD. =20 But you'd still need the prefix information that's found in the RA-PIO and the routing information that's found in the RA-RIO (that's very much like RPL 08's DPO). =20 So you see, it is actually very useful to RPL routers to carry those RA options unchanged within RPL's DIO =20 Current ND is the de facto abstraction for the host interface. =20 Some LLN/LoWPANs bring in a number of new concepts from route over. And now we're wondering what's the position of ND in that world.=20 =20 At one extreme we could say that the route over piece is a router problem and externalize it from ND unto RPL and such. At the other, we could consider that RPL is actually the component of ND that handles router to router. Why not after all? =20 Cheers, =20 Pascal =20 From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Friday, May 07, 2010 9:03 AM To: Kris Pister Cc: ROLL WG; 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IPaddress =20 Kris, =20 > But it's not a power issue =20 Agreed. This was meant to be an example only ;-) =20 - Anders =20 =20 =20 ________________________________ From: Kris Pister [mailto:pister@eecs.berkeley.edu]=20 Sent: Thursday, May 06, 2010 23:27 To: Anders Brandt Cc: ROLL WG; 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IPaddress Anders - there are many commercial networks (even in buildings and homes) where battery operated nodes are routers. I don't think that we should confuse the line/battery power issue with the host/router issue. There are many reasons why a node might choose or be designated to be a host not a router, so your question still stands. But it's not a power issue. =09 ksjp =09 Anders Brandt wrote:=20 Let me try one more time: =20 How much of this will I have to implement to be compliant with other LLN/RPL nodes? =20 In a home control/building environment, the notion of a router nodes is rather artificial. =20 I may have _host_nodes_. They are host nodes because they are sleeping (battery operated) and therefore they cannot participate in routing. They still have to get an IP address to talk to other IP hosts. =20 Alternatively, I may have combined _host&router_nodes_ which serve a purpose application-wise and at the same time happen to be routing resources. Do these hosts have to use another way of getting IP addresses just because they happen to be able to do routing? =20 From a designer's standpoint it does not seem quite elegant that I have to do use different methods depending on the power model for my node. Am I missing something here? =20 Thanks, Anders =20 =20 -----Original Message----- From: 6lowpan-bounces@ietf.org=20 [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Thursday, May 06, 2010 10:04 To: Pascal Thubert (pthubert) Cc: ROLL WG; zach.shelby@sensinode.com; 6lowpan@ietf.org Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a=20 node get an IPaddress) =20 On May 6, 2010, at 09:02, Pascal Thubert (pthubert) wrote: =20 =20 enable RPL aware hosts =20 Should we? =20 (Obviously, if a node really needs to know about RPL, it can=20 always become a router.) =20 If I understand you correctly, this is about hosts selecting=20 a specific RPL instance-ID for outgoing traffic. Traditionally, IP has used the TOS byte (Traffic Class in=20 IPv6) to select between different behaviors of the forwarding=20 system. What is it that the host wants to say by selecting a=20 specific RPL instance ID? Why can't the router make that=20 selection, e.g. based on the Traffic Class and the=20 destination address? =20 (Another interesting question is, for incoming traffic, how a=20 host selects which instances it wants to be part of. Is that=20 even a useful thing to do? Would that selection be made by=20 the host, by its first-hop router, or by some configuration agent?) =20 It would be useful to get more information about how=20 instance-IDs are intended to be used with RPL. =20 On the protocol side: If there really is something that a host needs to know about=20 RPL-specific information (instances or whatever), this could=20 be delivered in an ND option that could very well be defined=20 in an RPL-related document, no need to define it in=20 6LoWPAN-ND. Another way to set up this information would be=20 to configure it during commissioning or using a host=20 configuration protocol like DHCP. =20 Gruesse, Carsten =20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan =20 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CAEDE5.168B6FDA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

>Current ND is the de facto = abstraction for=20 the host interface.

....

>At the other, we could consider = that RPL is=20 actually the component of ND that handles router to router. Why not = after=20 all?

 

I understand that it makes sense in a = router=20 perspective to have this stuff in the routing = protocol.

My problem is that I have to make code for = very small=20 nodes.

 

Having two methods I need to support = translates into=20 two code blocks I need to include when building code for my=20 nodes.

For sure I need a way of assigning = addresses to=20 host nodes. This is a hard requirement. RPL assignment seems=20 optional.

If I can use the same code in the routing = nodes I have=20 more code space for the interesting parts.

Don't you agree?

 

>The=20 recent developments are that people tend to think that you can live with = an IPv6=20 derived from the MAC address without any DAD.

That=20 is fine with me - but I still need to convey prefix and default gateway, = so this=20 really does not change a lot, does it?.

 

Thanks,

 =20 Anders


From: Pascal Thubert (pthubert)=20 [mailto:pthubert@cisco.com]
Sent: Friday, May 07, 2010=20 14:47
To: Anders Brandt; Kris Pister
Cc: ROLL WG;=20 6lowpan@ietf.org
Subject: RE: [6lowpan] [Roll] how does a = node get=20 an IPaddress

Hi=20 Anders:

 

There=20 are a number of requirement drafts for this and = that.

 

I=20 think Julien and Mathilde tried to compile at some point what the arch = minimum=20 would be in a device to run IPv6 and looks OK.

 

The=20 recent developments are that people tend to think that you can live = with an=20 IPv6 derived from the MAC address without any = DAD.

 

But=20 you’d still need the prefix information that’s found in = the RA-PIO and the=20 routing information that’s found in the RA-RIO (that’s = very much like RPL 08’s=20 DPO).

 

So=20 you see, it is actually very useful to RPL routers to carry those RA = options=20 unchanged within RPL’s DIO

 

Current=20 ND is the de facto abstraction for the host = interface.

 

Some=20 LLN/LoWPANs bring in a number of new concepts from route over. And now = we’re=20 wondering what’s the position of ND in that world. =

 

At=20 one extreme we could say that the route over piece is a router problem = and=20 externalize it from ND unto RPL and such.

At=20 the other, we could consider that RPL is actually the component of ND = that=20 handles router to router. Why not after all?

 

Cheers,

 

Pascal

 

From:=20 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of=20 Anders Brandt
Sent: Friday, May 07, 2010 9:03 = AM
To:=20 Kris Pister
Cc: ROLL WG; 6lowpan@ietf.org
Subject: = Re:=20 [6lowpan] [Roll] how does a node get an=20 IPaddress

 

Kris,

 

>=20 But it's not a power issue

 

Agreed.=20 This was meant to be an example only ;-)

 

-=20 Anders

 

 

 

From: Kris = Pister=20 [mailto:pister@eecs.berkeley.edu]
Sent: Thursday, May 06, = 2010=20 23:27
To: Anders Brandt
Cc: ROLL WG;=20 6lowpan@ietf.org
Subject: Re: [Roll] [6lowpan] how does a = node get=20 an IPaddress

Anders - there are many commercial networks = (even in=20 buildings and homes) where battery operated nodes are routers.  = I don't=20 think that we should confuse the line/battery power issue with the=20 host/router issue.
There are many reasons why a node might choose = or be=20 designated to be a host not a router, so your question still = stands. =20 But it's not a power issue.

ksjp

Anders Brandt wrote:=20 

Let me try one more =
time:
 
How much of this =
will I have to implement to be compliant with =
other
LLN/RPL =
nodes?
 
In a home =
control/building environment, the notion of a router nodes =
is
rather =
artificial.
 
I may have =
_host_nodes_. They are host nodes because they are =
sleeping
(battery =
operated)
and therefore they cannot participate in =
routing.
They still have to get an IP address to =
talk to other IP =
hosts.
 
Alternatively, I =
may have combined _host&router_nodes_ which serve =
a
purpose application-wise
and =
at the same time happen to be routing resources.
Do =
these hosts have to use another way of getting IP addresses =
just
because they happen to
be =
able to do =
routing?
 
From a =
designer's standpoint it does not seem quite elegant that I =
have
to do use =
different
methods depending on the power model for =
my node. Am I missing =
something
here?
 
Thanks,
  =
Anders
 
  =

-----Original Message-----
From: 6lowpan-bounces@ietf.org =

[mailto:6lowpan-bounces@ietf.org<=
/A>] On Behalf Of Carsten Bormann
Sent: Thursday, =
May 06, 2010 10:04
To: Pascal Thubert =
(pthubert)
Cc: ROLL WG; zach.shelby@sensinode.com; =
6lowpan@ietf.org
Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a = 
node get an =
IPaddress)
 
On May 6, =
2010, at 09:02, Pascal Thubert (pthubert) =
wrote:
 
   =
; 
enable RPL aware hosts
 =
     
Should =
we?
 
(Obviously, if a =
node really needs to know about RPL, it can 
always =
become a router.)
 
If I =
understand you correctly, this is about hosts selecting =

a specific RPL instance-ID for outgoing =
traffic.
Traditionally, IP has used the TOS byte =
(Traffic Class in 
IPv6) to select between =
different behaviors of the forwarding =

system.  What is it that the host wants to =
say by selecting a 
specific RPL instance ID?  =
Why can't the router make that 
selection, e.g. =
based on the Traffic Class and the 
destination =
address?
 
(Another =
interesting question is, for incoming traffic, how a =

host selects which instances it wants to be part =
of.  Is that 
even a useful thing to do?  =
Would that selection be made by 
the host, by its =
first-hop router, or by some configuration =
agent?)
 
It would be =
useful to get more information about how =

instance-IDs are intended to be used with =
RPL.
 
On the protocol =
side:
If there really is something that a host =
needs to know about 
RPL-specific information =
(instances or whatever), this could 
be delivered =
in an ND option that could very well be defined 
in =
an RPL-related document, no need to define it in =

6LoWPAN-ND.  Another way to set up this =
information would be 
to configure it during =
commissioning or using a host 
configuration =
protocol like =
DHCP.
 
Gruesse, =
Carsten
 
________________=
_______________________________
6lowpan mailing =
list
6lowpan@ietf.org
https://www.ietf.o= rg/mailman/listinfo/6lowpan
 
    =

______________________________________=
_________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll
  =
------_=_NextPart_001_01CAEDE5.168B6FDA-- From pthubert@cisco.com Fri May 7 07:22:39 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82FEC3A6B40; Fri, 7 May 2010 07:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.964 X-Spam-Level: X-Spam-Status: No, score=-4.964 tagged_above=-999 required=5 tests=[AWL=-2.366, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns0CRdbeTTgZ; Fri, 7 May 2010 07:22:20 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 5A0063A6B29; Fri, 7 May 2010 07:21:53 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoBAG6+40uQ/uCWiWdsb2JhbACBPpxYFQEBAQoLEREGHKRymVqFFQQ X-IronPort-AV: E=Sophos;i="4.52,348,1270425600"; d="scan'208,217";a="6943188" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 07 May 2010 13:44:03 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o47ELdrx015137; Fri, 7 May 2010 14:21:39 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 16:21:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAEDF0.9B730CCB" Date: Fri, 7 May 2010 16:21:37 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01D608D6@XMB-AMS-107.cisco.com> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A120@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IPaddress Thread-Index: Acrt43JYXTd+ERJIS7GecowaH2hV/AAAEcVwAALBTZA= References: <6A2A459175DABE4BB11DE2026AA50A5D01D60847@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A120@zensys17.zensys.local> From: "Pascal Thubert (pthubert)" To: "Anders Brandt" X-OriginalArrivalTime: 07 May 2010 14:21:39.0496 (UTC) FILETIME=[9BC78A80:01CAEDF0] Cc: ROLL WG , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IPaddress X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 07 May 2010 14:22:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAEDF0.9B730CCB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Anders: =20 I agree you do not want to do things twice, mostly if you have to use different methods to do that.=20 To form your address, you need to get the PIO through some flooding/dissemination/gossiping mechanism. =20 Placing the PIO in the DIO saves you the support of flooding RAs as described for instance in the most recent ND draft. Once it has the the PIO, the node can do SLAAC for itself and it's all set.=20 =20 A real router serving hosts can insert the PIO in its RAs. RPL will ensure that it's still connected to the root and thus entitled to advertise the prefix. You'll note that in Dublin, 6LoWPAN voted support to Jonathan's draft that used trickle to disseminate RAs.=20 =20 Cheers, =20 Pascal =20 From: Anders Brandt [mailto:abr@sdesigns.dk]=20 Sent: Friday, May 07, 2010 2:59 PM To: Pascal Thubert (pthubert) Cc: ROLL WG; 6lowpan@ietf.org Subject: RE: [6lowpan] [Roll] how does a node get an IPaddress =20 =20 Hi Pascal, =20 >Current ND is the de facto abstraction for the host interface. .... =20 >At the other, we could consider that RPL is actually the component of ND that handles router to router. Why not after all? =20 =20 Iunderstand that it makes sense in a router perspective to have this stuff in the routing protocol. My problem is that I have to make code for very small nodes. =20 Having two methods I need to support translates into two code blocks I need to include when building code for my nodes. For sure I need a way of assigning addresses to host nodes. This is a hard requirement. RPL assignment seems optional. If I can use the same code in the routing nodes I have more code space for the interesting parts. Don't you agree? =20 >The recent developments are that people tend to think that you can live with an IPv6 derived from the MAC address without any DAD. That is fine with me - but I still need to convey prefix and default gateway, so this really does not change a lot, does it?. =20 Thanks, Anders =20 =09 ________________________________ From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Friday, May 07, 2010 14:47 To: Anders Brandt; Kris Pister Cc: ROLL WG; 6lowpan@ietf.org Subject: RE: [6lowpan] [Roll] how does a node get an IPaddress Hi Anders: =20 There are a number of requirement drafts for this and that. =20 I think Julien and Mathilde tried to compile at some point what the arch minimum would be in a device to run IPv6 and looks OK. =20 The recent developments are that people tend to think that you can live with an IPv6 derived from the MAC address without any DAD. =20 But you'd still need the prefix information that's found in the RA-PIO and the routing information that's found in the RA-RIO (that's very much like RPL 08's DPO). =20 So you see, it is actually very useful to RPL routers to carry those RA options unchanged within RPL's DIO =20 Current ND is the de facto abstraction for the host interface. =20 Some LLN/LoWPANs bring in a number of new concepts from route over. And now we're wondering what's the position of ND in that world.=20 =20 At one extreme we could say that the route over piece is a router problem and externalize it from ND unto RPL and such. At the other, we could consider that RPL is actually the component of ND that handles router to router. Why not after all? =20 Cheers, =20 Pascal =20 From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Friday, May 07, 2010 9:03 AM To: Kris Pister Cc: ROLL WG; 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IPaddress =20 Kris, =20 > But it's not a power issue =20 Agreed. This was meant to be an example only ;-) =20 - Anders =20 =20 =20 ________________________________ From: Kris Pister [mailto:pister@eecs.berkeley.edu]=20 Sent: Thursday, May 06, 2010 23:27 To: Anders Brandt Cc: ROLL WG; 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IPaddress Anders - there are many commercial networks (even in buildings and homes) where battery operated nodes are routers. I don't think that we should confuse the line/battery power issue with the host/router issue. There are many reasons why a node might choose or be designated to be a host not a router, so your question still stands. But it's not a power issue. =09 ksjp =09 Anders Brandt wrote:=20 Let me try one more time: =20 How much of this will I have to implement to be compliant with other LLN/RPL nodes? =20 In a home control/building environment, the notion of a router nodes is rather artificial. =20 I may have _host_nodes_. They are host nodes because they are sleeping (battery operated) and therefore they cannot participate in routing. They still have to get an IP address to talk to other IP hosts. =20 Alternatively, I may have combined _host&router_nodes_ which serve a purpose application-wise and at the same time happen to be routing resources. Do these hosts have to use another way of getting IP addresses just because they happen to be able to do routing? =20 From a designer's standpoint it does not seem quite elegant that I have to do use different methods depending on the power model for my node. Am I missing something here? =20 Thanks, Anders =20 =20 -----Original Message----- From: 6lowpan-bounces@ietf.org=20 [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Thursday, May 06, 2010 10:04 To: Pascal Thubert (pthubert) Cc: ROLL WG; zach.shelby@sensinode.com; 6lowpan@ietf.org Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a=20 node get an IPaddress) =20 On May 6, 2010, at 09:02, Pascal Thubert (pthubert) wrote: =20 =20 enable RPL aware hosts =20 Should we? =20 (Obviously, if a node really needs to know about RPL, it can=20 always become a router.) =20 If I understand you correctly, this is about hosts selecting=20 a specific RPL instance-ID for outgoing traffic. Traditionally, IP has used the TOS byte (Traffic Class in=20 IPv6) to select between different behaviors of the forwarding=20 system. What is it that the host wants to say by selecting a=20 specific RPL instance ID? Why can't the router make that=20 selection, e.g. based on the Traffic Class and the=20 destination address? =20 (Another interesting question is, for incoming traffic, how a=20 host selects which instances it wants to be part of. Is that=20 even a useful thing to do? Would that selection be made by=20 the host, by its first-hop router, or by some configuration agent?) =20 It would be useful to get more information about how=20 instance-IDs are intended to be used with RPL. =20 On the protocol side: If there really is something that a host needs to know about=20 RPL-specific information (instances or whatever), this could=20 be delivered in an ND option that could very well be defined=20 in an RPL-related document, no need to define it in=20 6LoWPAN-ND. Another way to set up this information would be=20 to configure it during commissioning or using a host=20 configuration protocol like DHCP. =20 Gruesse, Carsten =20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan =20 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CAEDF0.9B730CCB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Anders:

 

I agree you do not want to do things twice, mostly if you have to use = different methods to do that.

To form your address, you need to get the PIO through some = flooding/dissemination/gossiping mechanism.

 

Placing the PIO in the DIO saves you the support of flooding RAs as = described for instance in the most recent ND = draft.

Once it has the the PIO,  the node can do SLAAC for itself and = it’s all set.

 

A real router serving hosts can insert the PIO in its RAs. RPL will = ensure that it’s still connected to the root and thus entitled to = advertise the prefix.

You’ll note that in Dublin, 6LoWPAN voted support to = Jonathan’s draft that used trickle to disseminate RAs. =

 

Cheers,

 

Pascal

 

From: Anders Brandt [mailto:abr@sdesigns.dk]
Sent: Friday, = May 07, 2010 2:59 PM
To: Pascal Thubert = (pthubert)
Cc: ROLL WG; 6lowpan@ietf.org
Subject: = RE: [6lowpan] [Roll] how does a node get an = IPaddress

 

 

Hi Pascal,

 

>Current ND is the de facto abstraction for the host = interface.

....

 

>At the other, we could consider that RPL is actually the = component of ND that handles router to router. Why not after = all?

 

 

Iunderstand that it makes sense in a router perspective to have this = stuff in the routing protocol.

My problem is that I have to make code for very small = nodes.

 

Having two methods I need to support translates into two code blocks = I need to include when building code for my = nodes.

For sure I need a way of assigning addresses to host nodes. This = is a hard requirement. RPL assignment seems = optional.

If I can use the same code in the routing nodes I have more code = space for the interesting parts.

Don't you agree?

 

>The recent developments are that people tend to think that you = can live with an IPv6 derived from the MAC address without any = DAD.

That is fine with me - but I still need to convey prefix and default = gateway, so this really does not change a lot, does = it?.

 

Thanks,

Anders

 

From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] =
Sent: Friday, May 07, 2010 14:47
To: Anders Brandt; = Kris Pister
Cc: ROLL WG; 6lowpan@ietf.org
Subject: = RE: [6lowpan] [Roll] how does a node get an IPaddress

Hi Anders:

 

There are a number of requirement drafts for this and = that.

 

I think Julien and Mathilde tried to compile at some point what the = arch minimum would be in a device to run IPv6 and looks = OK.

 

The recent developments are that people tend to think that you can = live with an IPv6 derived from the MAC address without any = DAD.

 

But you’d still need the prefix information that’s found = in the RA-PIO and the routing information that’s found in the = RA-RIO (that’s very much like RPL 08’s = DPO).

 

So you see, it is actually very useful to RPL routers to carry those = RA options unchanged within RPL’s DIO

 

Current ND is the de facto abstraction for the host = interface.

 

Some LLN/LoWPANs bring in a number of new concepts from route over. = And now we’re wondering what’s the position of ND in that = world.

 

At one extreme we could say that the route over piece is a router = problem and externalize it from ND unto RPL and = such.

At the other, we could consider that RPL is actually the component of = ND that handles router to router. Why not after = all?

 

Cheers,

 

Pascal

 

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Anders Brandt
Sent: Friday, May 07, 2010 9:03 = AM
To: Kris Pister
Cc: ROLL WG; = 6lowpan@ietf.org
Subject: Re: [6lowpan] [Roll] how does a node = get an IPaddress

 

Kr= is,

 

&g= t; But it's not a power issue

 

Ag= reed. This was meant to be an example only = ;-)

 

- = Anders

 

 

 

From:= = Kris Pister [mailto:pister@eecs.berkeley.edu]
Sent: Thursday, = May 06, 2010 23:27
To: Anders Brandt
Cc: ROLL WG; = 6lowpan@ietf.org
Subject: Re: [Roll] [6lowpan] how does a node = get an IPaddress

Anders - = there are many commercial networks (even in buildings and homes) where = battery operated nodes are routers.  I don't think that we should = confuse the line/battery power issue with the host/router = issue.
There are many reasons why a node might choose or be = designated to be a host not a router, so your question still = stands.  But it's not a power issue.

ksjp

Anders = Brandt wrote: 

Let me try one more =
time:
 
How much of this =
will I have to implement to be compliant with =
other
LLN/RPL =
nodes?
 
In a home =
control/building environment, the notion of a router nodes =
is
rather =
artificial.
 
I may have =
_host_nodes_. They are host nodes because they are =
sleeping
(battery =
operated)
and therefore they cannot participate in =
routing.
They still have to get an IP address to =
talk to other IP =
hosts.
 
Alternatively, I =
may have combined _host&router_nodes_ which serve =
a
purpose application-wise
and =
at the same time happen to be routing resources.
Do =
these hosts have to use another way of getting IP addresses =
just
because they happen to
be =
able to do =
routing?
 
From a =
designer's standpoint it does not seem quite elegant that I =
have
to do use =
different
methods depending on the power model for =
my node. Am I missing =
something
here?
 
Thanks,
  =
Anders
 
  =

-----Original =
Message-----
From: 6lowpan-bounces@ietf.org =

[mailto:6lowpan-bounces@ietf.org<=
/a>] On Behalf Of Carsten Bormann
Sent: Thursday, =
May 06, 2010 10:04
To: Pascal Thubert =
(pthubert)
Cc: ROLL WG; zach.shelby@sensinode.com; =
6lowpan@ietf.org
Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a = 
node get an =
IPaddress)
 
On May 6, =
2010, at 09:02, Pascal Thubert (pthubert) =
wrote:
 
   =
; 
enable RPL aware =
hosts
 =
     
Should =
we?
 
(Obviously, if a =
node really needs to know about RPL, it can 
always =
become a router.)
 
If I =
understand you correctly, this is about hosts selecting =

a specific RPL instance-ID for outgoing =
traffic.
Traditionally, IP has used the TOS byte =
(Traffic Class in 
IPv6) to select between =
different behaviors of the forwarding =

system.  What is it that the host wants to =
say by selecting a 
specific RPL instance ID?  =
Why can't the router make that 
selection, e.g. =
based on the Traffic Class and the 
destination =
address?
 
(Another =
interesting question is, for incoming traffic, how a =

host selects which instances it wants to be part =
of.  Is that 
even a useful thing to do?  =
Would that selection be made by 
the host, by its =
first-hop router, or by some configuration =
agent?)
 
It would be =
useful to get more information about how =

instance-IDs are intended to be used with =
RPL.
 
On the protocol =
side:
If there really is something that a host =
needs to know about 
RPL-specific information =
(instances or whatever), this could 
be delivered =
in an ND option that could very well be defined 
in =
an RPL-related document, no need to define it in =

6LoWPAN-ND.  Another way to set up this =
information would be 
to configure it during =
commissioning or using a host 
configuration =
protocol like =
DHCP.
 
Gruesse, =
Carsten
 
________________=
_______________________________
6lowpan mailing =
list
6lowpan@ietf.org
https://www.ietf.o= rg/mailman/listinfo/6lowpan
 
    =

______________________________________=
_________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll
  =
------_=_NextPart_001_01CAEDF0.9B730CCB-- From pthubert@cisco.com Fri May 7 07:34:08 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAD313A6B48; Fri, 7 May 2010 07:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.91 X-Spam-Level: X-Spam-Status: No, score=-4.91 tagged_above=-999 required=5 tests=[AWL=-2.312, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un-Lr0ej28E8; Fri, 7 May 2010 07:34:00 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id ACAB53A6857; Fri, 7 May 2010 07:33:58 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoBALbB40uQ/uCWiWdsb2JhbACBPpxYFQEBAQoLEREGHKUSmV2FFQQ X-IronPort-AV: E=Sophos;i="4.52,348,1270425600"; d="scan'208,217";a="6944300" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 07 May 2010 13:56:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o47EXiuK019115; Fri, 7 May 2010 14:33:45 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 16:33:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAEDF2.4BC4B1F2" Date: Fri, 7 May 2010 16:33:41 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01D608E0@XMB-AMS-107.cisco.com> In-Reply-To: <4BE3FC4A.20007@gridmerge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [6lowpan] how does a node get an IP address Thread-Index: Acrt2j2y9FWyvMqTTrGzkrAbhxVU/QAFop2A References: <7069.1272031181@marajade.sandelman.ca><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> <87zl0dz0m9.fsf@kelsey-ws.hq.ember.com> <4BE300E6.2020703@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D01D605A8@XMB-AMS-107.cisco.com> <4BE3FC4A.20007@gridmerge.com> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 07 May 2010 14:33:44.0876 (UTC) FILETIME=[4C23BEC0:01CAEDF2] Cc: roll@ietf.org, zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 07 May 2010 14:34:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAEDF2.4BC4B1F2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert: =20 Your +1 could be misinterpreted then... I think Carsten did. =20 The flow label helps the router select the instance for a packet. It does not help a host that needs to select a router that serves that instance. A plain host (that does not support RPL) will need to find that in RAs. In a same fashion, it will need to place what it's looking for in RS (like we'll do in DIS). And the new ND registration will have to indicate into which instances the registration must be injected as a DAO. =20 Do you agree so far? =20 The DODAG ID is not the appropriate information for the host, unless it is concerned with DAG multihoming and such, which I would not expect. The router can and will switch DODAG within the instance and the host will not care, since its applications will be served either way.=20 When the router leaves the instance entirely, then the node will care, and it needs to know. At worst, we can achieve that with a new unreachable code. =20 Finally, a root might use the same DODAG ID in multiple instances. So the router could be confused if the host only indicated a DODAG ID... =20 Still in agreement? =20 On the side, we discussed for P2P about making local instances that actually depend on the DODAG ID so that the fully qualified instance ID would really be the tupple (DODAG ID, instanceID). That's still in limbo though I do think we need it.=20 =20 What's your take on this? =20 =20 Pascal =20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: Friday, May 07, 2010 1:41 PM To: Pascal Thubert (pthubert) Cc: Richard Kelsey; zach.shelby@sensinode.com; roll@ietf.org; 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IP address =20 Hi Pascal, I understand what you're saying and agree that in the case of multiple RPL instances, whereby each RPL instance is characterized by potentially different metrics (that's the point of them, right?), you would need some sort of qualification at the packet originator as to which RPL instance it ends up choosing for its route to its destination. This is done using the flow label. On the other hand, a DODAG is, as its name implies, a destination oriented DAG. Therefore the DODAG ID is the general discriminator within a RPL instance for which route a packet takes based on its destination. There is no need for any other additional information, surely? So that's what the +1 was for. The spec. seems a little confused on this anyway. In section 7.2 it says the RPLInstanceID field is an "8-bit field indicating the DODAG instance along which the packet is sent". But the DODAG instance is an instance within a RPL instance. Can you clarify this? In general, I find the instances confusing, as they are often considered as a tuple (RPLID, DODAGID, DODAGSeqNum). However, transitioning from (1,1,1) to (1,1,2) is not the same as transitioning from (1,1,1) to (1,2,1) and this is not clear in the specification. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 On 07/05/2010 7:08 AM, Pascal Thubert (pthubert) wrote:=20 Hi Robert and Richard: =20 We designed instances to enable to support multiple sorts of traffic with different requirements. =20 The instance is the network response to the application needs. The application resides in the host, even if routers sometimes play both roles. The application needs to signal the instance one way or another in its packets, and we use flow labels for that. So far so good.=20 =20 What's missing: =20 The host also needs to join the RPL networks that support the instances that it needs. That must be signaled in the router to host interface. The host also needs to be advertised in the RPL networks that support the instances that it needs. That must be signaled in the host to router interface. =20 >From there I think you've got the logic reverse: You're correct that ROLL supports a host with no RPL extension using instance 0 / flow label 0. But still the host to router interface needs to be augmented for an application residing on the host to benefit from ROLL instances.=20 =20 What I'm reading below is "a host MUST be a router in order to comply with the ROLL MUST of supporting multiple types of traffic". =20 Well, -1. =20 Pascal =20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: Thursday, May 06, 2010 7:48 PM To: Richard Kelsey Cc: Pascal Thubert (pthubert); zach.shelby@sensinode.com; roll@ietf.org; 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IP address =20 +1 Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 =09 On 06/05/2010 1:16 PM, Richard Kelsey wrote:=20 Date: Thu, 6 May 2010 09:02:28 +0200 From: "Pascal Thubert (pthubert)" =20 =20 [Pascal] 6LoWPAN ND needs some addition to enable RPL aware hosts. In particular around instance IDs.=20 =20 =20 Pascal, I disagree with "needs". The ability to select an instance ID for a particular message is an optional extra. RPL works fine without it. I am okay with limiting instance ID selection to routers. =20 -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 =20 ------_=_NextPart_001_01CAEDF2.4BC4B1F2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert:

 

Your +1 could be misinterpreted then… I think Carsten = did.

 

The flow label helps the router select the instance for a packet. It = does not help a host that needs to select a router that serves that = instance. A plain host (that does not support RPL) will need to find = that in RAs. In a same fashion, it will need to place what it’s = looking for in RS (like we’ll do in DIS). And the new ND = registration will have to indicate into which instances the registration = must be injected as a DAO.

 

Do you agree so far?

 

The DODAG ID is not  the appropriate information for the host, = unless it is concerned with DAG multihoming and such, which I would not = expect.

The router can and will switch DODAG within the instance and the host = will not care, since its applications will be served either way. =

When the router leaves the instance entirely, then the node will = care, and it needs to know. At worst, we can achieve that with a new = unreachable code.

 

Finally, a root might use the same DODAG ID in multiple instances. So = the router could be confused if the host only indicated a DODAG = ID…

 

Still in agreement?

 

On the side, we discussed for P2P  about making local instances = that actually depend on the DODAG ID so that the fully qualified = instance ID would really be the tupple (DODAG ID, instanceID). = That’s still in limbo though I do think we need it. =

 

What’s your take on this?

 

 

Pascal

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com] =
Sent: Friday, May 07, 2010 1:41 PM
To: Pascal = Thubert (pthubert)
Cc: Richard Kelsey; = zach.shelby@sensinode.com; roll@ietf.org; = 6lowpan@ietf.org
Subject: Re: [Roll] [6lowpan] how does a node = get an IP address

 

Hi = Pascal,

I understand what you're saying and agree that in the = case of multiple RPL instances, whereby each RPL instance is = characterized by potentially different metrics (that's the point of = them, right?), you would need some sort of qualification at the packet = originator as to which RPL instance it ends up choosing for its route to = its destination. This is done using the flow label.

On the other = hand, a DODAG is, as its name implies, a destination oriented DAG. = Therefore the DODAG ID is the general discriminator within a RPL = instance for which route a packet takes based on its destination. There = is no need for any other additional information, surely? So that's what = the +1 was for.

The spec. seems a little confused on this anyway. = In section 7.2 it says the RPLInstanceID field is an "8-bit field = indicating the DODAG instance along which the packet is sent". But = the DODAG instance is an instance within a RPL instance. Can you clarify = this? In general, I find the instances confusing, as they are often = considered as a tuple (RPLID, DODAGID, DODAGSeqNum). However, = transitioning from (1,1,1) to (1,1,2) is not the same as transitioning = from (1,1,1) to (1,2,1) and this is not clear in the = specification.

Robert

Robert = Cragie (Pacific Gas & Electric)

Gridmerge = Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) = 1924 910888
http://www.gridmerge.com


On 07/05/2010 7:08 AM, Pascal = Thubert (pthubert) wrote:

Hi Robert and Richard:

 

We designed instances to enable to support multiple sorts of traffic = with different requirements.

 

The instance is the network response to the application needs. The = application resides in the host, even if routers sometimes play both = roles.

The application needs to signal the instance one way or another in = its packets, and we use flow labels for that. So far so good. =

 

What’s missing:

 

The host also needs to join the RPL networks that support the = instances that it needs. That must be signaled in the router to host = interface.

The host also needs to be advertised in the RPL networks that support = the instances that it needs. That must be signaled in the host to router = interface.

 

From there I think you’ve got the logic = reverse:

You’re correct that ROLL supports a host with no RPL extension = using instance 0 / flow label 0.

But still the host to router interface needs to be augmented for an = application residing on the host to benefit from ROLL instances. =

 

What I’m reading below is “a host MUST be a router in = order to comply with the ROLL MUST of supporting multiple types of = traffic”.

 

Well, -1.

 

Pascal

 

From: Robert Cragie [mailto:robert.cragie@gridmerg= e.com]
Sent: Thursday, May 06, 2010 7:48 PM
To: = Richard Kelsey
Cc: Pascal Thubert (pthubert); zach.shelby@sensinode.com; = roll@ietf.org; 6lowpan@ietf.org
Subject: = Re: [Roll] [6lowpan] how does a node get an IP = address

 

+1

Robert Cragie = (Pacific Gas & Electric)

Gridmerge Ltd.
89 = Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 = 910888
http://www.gridmerge.com


On 06/05/2010 1:16 PM, Richard = Kelsey wrote: 

Date: Thu, 6 May =
2010 09:02:28 +0200
From: "Pascal Thubert =
(pthubert)" <pthubert@cisco.com>
 
[Pascal] 6LoWPAN ND needs some =
addition to enable RPL aware hosts. In
particular =
around instance IDs. =

    
 
Pascal, I disagree with =
"needs".  The ability to select =
an
instance ID for a particular message is an =
optional extra.
RPL works fine without it.  I =
am okay with limiting instance
ID selection to =
routers.
 
  &nb=
sp;           &nbs=
p;            =
;      -Richard =
Kelsey
_____________________________________________=
__
Roll mailing list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll
 
 
------_=_NextPart_001_01CAEDF2.4BC4B1F2-- From richard.kelsey@ember.com Fri May 7 07:58:53 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68DE33A6B42; Fri, 7 May 2010 07:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.749, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvwWCod1YCXu; Fri, 7 May 2010 07:58:52 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 99AF13A6B08; Fri, 7 May 2010 07:58:52 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 May 2010 11:01:59 -0400 Date: Fri, 07 May 2010 10:52:11 -0400 Message-Id: <87wrvfzrvo.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D01D608E0@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <7069.1272031181@marajade.sandelman.ca><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> <87zl0dz0m9.fsf@kelsey-ws.hq.ember.com> <4BE300E6.2020703@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D01D605A8@XMB-AMS-107.cisco.com> <4BE3FC4A.20007@gridmerge.com> <6A2A459175 DABE4BB11DE2026AA50A5D01D608E0@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 07 May 2010 15:01:59.0538 (UTC) FILETIME=[3E3CA520:01CAEDF6] Cc: roll@ietf.org, zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 07 May 2010 14:58:53 -0000 > Date: Fri, 7 May 2010 16:33:41 +0200 > From: "Pascal Thubert (pthubert)" > > The flow label helps the router select the instance for a packet. "Helps"? Doesn't the flow label tell the router exactly which instance to use? > It does not help a host that needs to select a router that serves that > instance. The trouble I have with this is that "select a router" sounds a lot like routing. We already have a mechanism for selecting which router to send a packet to: DIOs. If a device wants to select between next hops based on routing metrics then it should be a router. Why is this such a burden? Listening to DIOs and making routing decisions based on them does not require sending DIOs or forwarding packets for others. -Richard Kelsey From mdurvy@cisco.com Fri May 7 08:27:16 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93F13A6957; Fri, 7 May 2010 08:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.042 X-Spam-Level: X-Spam-Status: No, score=-10.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIzQ4VSCaEnW; Fri, 7 May 2010 08:27:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E10213A6869; Fri, 7 May 2010 08:27:14 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4235 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIBAJvO40uQ/uCWiWdsb2JhbACeFxUBAQEKCxERBhylUJlXhRUE X-IronPort-AV: E=Sophos;i="4.52,349,1270425600"; d="p7s'?scan'208";a="60867632" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 07 May 2010 15:27:01 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o47FR1tV004781; Fri, 7 May 2010 15:27:01 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 17:26:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 May 2010 17:26:58 +0200 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0511_01CAEE0A.7F1DBF20"; protocol="application/x-pkcs7-signature" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE01FE6CD3@XMB-AMS-103.cisco.com> In-Reply-To: <87wrvfzrvo.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: Acrt9diPR0taILqFS/G/lh/pYt9JGwAA1TLA References: <7069.1272031181@marajade.sandelman.ca><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com><87zl0dz0m9.fsf@kelsey-ws.hq.ember.com><4BE300E6.2020703@gridmerge.com><6A2A459175DABE4BB11DE2026AA50A5D01D605A8@XMB-AMS-107.cisco.com><4BE3FC4A.20007@gridmerge.com> <6A2A459175DABE 4BB11DE2 026AA50A5D01 D608E0@XMB-AMS-107.cisco.com> <87wrvfzrvo.fsf@kelsey-ws.hq.ember.com> From: "Mathilde Durvy (mdurvy)" To: "Richard Kelsey" , "Pascal Thubert (pthubert)" X-OriginalArrivalTime: 07 May 2010 15:26:59.0303 (UTC) FILETIME=[BC2A9F70:01CAEDF9] Cc: roll@ietf.org, zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 07 May 2010 15:27:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0511_01CAEE0A.7F1DBF20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Richard, > Date: Fri, 7 May 2010 16:33:41 +0200 > From: "Pascal Thubert (pthubert)" > > The flow label helps the router select the instance for a packet. "Helps"? Doesn't the flow label tell the router exactly which instance to use? > It does not help a host that needs to select a router that serves that > instance. The trouble I have with this is that "select a router" sounds a lot like routing. We already have a mechanism for selecting which router to send a packet to: DIOs. If a device wants to select between next hops based on routing metrics then it should be a router. Why is this such a burden? Listening to DIOs and making routing decisions based on them does not require sending DIOs or forwarding packets for others. [Mathilde] What you are describing looks like a RPL leaf node but does not really need the IPv6 router functionalities i.e. forwarding, sending RA, etc. This is exactly what I was trying to point out when I was asking if a RPL leaf node could be an IPv6 host... Best, Mathilde ------=_NextPart_000_0511_01CAEE0A.7F1DBF20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2jCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTFMIIDraADAgECAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkxMTI2MDAw MDAwWhcNMTAxMTI2MjM1OTU5WjCCARIxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG dWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1hdGhpbGRlIER1cnZ5MR8wHQYJKoZIhvcNAQkBFhBtZHVy dnlAY2lzY28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR9oVSAz6Tlt7xUvAb+IKp aqKdu1dh0cihpjNNzndIzit+ZWpixDZ8tWBtpZ7T2jBC+SiyquqIrin/TD4jlk60y4OBBeF2zlJa c6P0Ay8g4WjDRnvJP93Wz93W32bgjtV1R7FRlWUxPjn9QUDcq4PIHd4qFKSiOMfKk1OijYeWRQID AQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAU BggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRh bElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQA9I2FwWjWGMNapHvMFY2LZN+qr3cX6ILBUZ1AxypApr5B2Hl8YXDMA6o8Gtd5J2wxkJmEAbqXT zkoVWspigsclFSbGDu5V0ITLLZzzCXvwnpeaUD4F9GngqdkNUZkqXirqaMZxQTiaI5Hue2RX3f7b Ew4GqU+KMg6meor5iMoyGl/mtZ0LSPj6ZltNaG7ElQoyTXfdBGXlEm8z2uJhtb42Ys2OUptP1v3x jhxT2njv9NMcBH4q7S6y+op0aFrVsNLP7+qcPSBZlEcav3vyNSygxnqyx+pMJmgWH+/VdwsbSIDB FAo4DoI+fe2pUIeqRx6yP9s+e21BRiSPxvBtVe+JMIIEzDCCBDWgAwIBAgIQHK6da5r05i8iiqPa dGFsHjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkwHhcNMDUxMDI4MDAwMDAwWhcNMTUxMDI3MjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAyd+s5+r4+AMUxACS1cF+NsI873xyFcvAq4w9HJXObx4QLD8A7Zcm5rbH5q1DHT+kh0dH TD5U+Gz4x/yxnr0wcLyXsQMF6pXxrUDFRHpLBaLyYPzXOmVi7/8Qe6JWu8VOcC3Woh887bBC6F6N VyGsppnZEenSGgfAdEdCC/zFNOr95rok0R0IFTei13PPAUEvY7I6P76lGm70yUpbPZWmFbs1Ahn5 1O+8jw5xdlm7S7Y+1vxaFvTWDonySf5sDO0V6dmIdZx5zmAn3bmtdc4vc5V6QDqFdUmwuN9ovKvN E4KFEVCj4DwLrsAKU83XMG+FMkYb5EkQwmzirx95/9u0tQIDAQABo4IBhDCCAYAwEgYDVR0TAQH/ BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQU EX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2ln bi5jb20vcGNhMS5jcmwwgYEGA1UdIwR6MHihY6RhMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eYIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQEFBQADgYEAsS/ZluGS ou6BYOXIKiD74Wcs1gCYU6MCG+mQS/gYRJ8PRvf6oP7THRij0r8c7NYZn0pNQ/jKu74TgEkF3SFz M1fCQlq++gCTsuYEMZFOXTzwcwU3Y+u/g1mY/Wbe6YYympIpPDquVNqmElGxj8jK00d45tulHocG 49EUwMIh9roxggRzMIIEbwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDUwNzE1MjY1OFowIwYJKoZI hvcNAQkEMRYEFLum2vbqiicWKFO307s/5T1f487pMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAFlt0 d1vsP7XQYJNcz/m5heImzL4/ZpfRyXKODNuLNEH+3gGAtl/1Z35SP8yoJT2LwTJYJFA9KLBQBCOM WYsRv+87Vp0l00HmbnYAM3Ithv6ZHfgJxaGzXR+kHyZxX9NWg5hh7G+AY37qaPjYyh5XGn2UZAht LhZjBM2FzzB4ZfIAAAAAAAA= ------=_NextPart_000_0511_01CAEE0A.7F1DBF20-- From pthubert@cisco.com Sun May 9 09:43:12 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596513A6A59; Sun, 9 May 2010 09:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.939 X-Spam-Level: X-Spam-Status: No, score=-7.939 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c2vR5sHzlO2; Sun, 9 May 2010 09:43:10 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A04A23A6987; Sun, 9 May 2010 09:43:08 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHCD5kurR7Ht/2dsb2JhbACeFXGiUZgxhRUE X-IronPort-AV: E=Sophos;i="4.52,357,1270425600"; d="scan'208";a="194858253" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 09 May 2010 16:42:51 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o49GgofJ004219; Sun, 9 May 2010 16:42:50 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 May 2010 18:42:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {A7188AD3-CC49-46BF-A441-14A57ACAEE1D} MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: CgnI IOMF I0mG XP0U d0CV ey58 fxwb gfoy gwNk k+Fb me20 pGtO t5R7 yDFx 2BRx 21Wq; 5; NgBsAG8AdwBwAGEAbgBAAGkAZQB0AGYALgBvAHIAZwA7AHIAaQBjAGgAYQByAGQALgBrAGUAbABzAGUAeQBAAGUAbQBiAGUAcgAuAGMAbwBtADsAcgBvAGIAZQByAHQALgBjAHIAYQBnAGkAZQBAAGcAcgBpAGQAbQBlAHIAZwBlAC4AYwBvAG0AOwByAG8AbABsAEAAaQBlAHQAZgAuAG8AcgBnADsAegBhAGMAaAAuAHMAaABlAGwAYgB5AEAAcwBlAG4AcwBpAG4AbwBkAGUALgBjAG8AbQA=; Sosha1_v1; 7; {A7188AD3-CC49-46BF-A441-14A57ACAEE1D}; cAB0AGgAdQBiAGUAcgB0AEAAYwBpAHMAYwBvAC4AYwBvAG0A; Sun, 09 May 2010 16:41:12 GMT; UgBFADoAIABbAFIAbwBsAGwAXQAgAFsANgBsAG8AdwBwAGEAbgBdACAAIABoAG8AdwAgAGQAbwBlAHMAIABhACAAbgBvAGQAZQAgAGcAZQB0ACAAYQBuACAASQBQACAAYQBkAGQAcgBlAHMAcwA= Content-class: urn:content-classes:message Date: Sun, 9 May 2010 18:41:12 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01D60A35@XMB-AMS-107.cisco.com> In-Reply-To: <87wrvfzrvo.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [6lowpan] how does a node get an IP address Thread-Index: Acrt9c08ONYkSO7ZQnOLXzZHmfHc8QBnfGOA References: <6A2A459175DABE4BB11DE2026AA50A5D01D608E0@XMB-AMS-107.cisco.com>(pthubert@cisco.com) <87wrvfzrvo.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 09 May 2010 16:42:49.0684 (UTC) FILETIME=[A93B2940:01CAEF96] Cc: roll@ietf.org, zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sun, 09 May 2010 16:43:12 -0000 Hi Richard > > The flow label helps the router select the instance for a packet. >=20 > "Helps"? Doesn't the flow label tell the router exactly which instance to use? At the moment you're correct, it's one to one. I've heard voices (was that Kris and Phil?) asking for a more complex stateful mapping at the RPL network ingress, and a new field in the new RPL option for the instance. My vote is to leave the instance ID in the flow label where it is today, since it is end to end application data. While I agree that the loop avoidance data fits very well in a hop by hop option long as the option stays contained in the RPL network. Which is what Jonathan's draft does for all I understand so I'm fully happy there. >=20 > The trouble I have with this is that "select a router" > sounds a lot like routing. We already have a mechanism for selecting which > router to send a packet to: DIOs. > If a device wants to select between next hops based on routing metrics then > it should be a router. >=20 > Why is this such a burden? Listening to DIOs and making routing decisions > based on them does not require sending DIOs or forwarding packets for > others. In the host world, there is such a thing as a default router list. The host builds that list listening to RAs, and applies its best practice to select the router it will use for a given packet out. A number of considerations will influence that decision, like the age information, Mobile IP information, multihoming information, etc... RFC 4191 is an obvious such consideration that provides guidance to proactively setup a table that redirects would have setup reactively anyway. You'll note that RFC 4191 is very voluntarily NOT a routing protocol thing, and really a router to host to interface. The key here is that the preference IS NOT a distance. Other hints come from the mechanics used (RA most usually is router to host though it's been extended to R2R sometimes like in MIPv6). In a same fashion as routing information can be transformed into a RFC 4191 RIO, instance information should be made available to the host. Pascal > -----Original Message----- > From: Richard Kelsey [mailto:richard.kelsey@ember.com] > Sent: Friday, May 07, 2010 4:52 PM > To: Pascal Thubert (pthubert) > Cc: robert.cragie@gridmerge.com; zach.shelby@sensinode.com; > roll@ietf.org; 6lowpan@ietf.org > Subject: Re: [Roll] [6lowpan] how does a node get an IP address >=20 > References: > <7069.1272031181@marajade.sandelman.ca><4BD58ED9.8070401@gridmerg > e.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys > .local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83 > e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB- > AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey- > ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd42 > 9wp.fsf@kelsey- > ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula > .fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS- > 107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB- > AMS-103.cisco.com> > <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS- > 107.cisco.com> > <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS- > 107.cisco.com> <87zl0dz0m9.fsf@kelsey-ws.hq.ember.com> > <4BE300E6.2020703@gridmerge.com> > <6A2A459175DABE4BB11DE2026AA50A5D01D605A8@XMB-AMS- > 107.cisco.com> <4BE3FC4A.20007@gridmerge.com> > <6A2A459175DABE4BB11DE2026AA50A5D01D608E0@XMB-AMS- > 107.cisco.com> > X-OriginalArrivalTime: 07 May 2010 15:01:59.0538 (UTC) > FILETIME=3D[3E3CA520:01CAEDF6] > Return-Path: richard.kelsey@ember.com >=20 > > Date: Fri, 7 May 2010 16:33:41 +0200 > > From: "Pascal Thubert (pthubert)" > > > > The flow label helps the router select the instance for a packet. >=20 > "Helps"? Doesn't the flow label tell the router exactly which instance to use? >=20 > > It does not help a host that needs to select a router that serves that > > instance. >=20 > The trouble I have with this is that "select a router" > sounds a lot like routing. We already have a mechanism for selecting which > router to send a packet to: DIOs. > If a device wants to select between next hops based on routing metrics then > it should be a router. >=20 > Why is this such a burden? Listening to DIOs and making routing decisions > based on them does not require sending DIOs or forwarding packets for > others. >=20 > -Richard Kelsey From Mohana.Jeyatharan@sg.panasonic.com Sun May 9 20:19:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E99B3A6ACA for <6lowpan@core3.amsl.com>; Sun, 9 May 2010 20:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.315 X-Spam-Level: *** X-Spam-Status: No, score=3.315 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_52=0.6, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKyAPVLDaq7n for <6lowpan@core3.amsl.com>; Sun, 9 May 2010 20:19:56 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 6A1163A6AD3 for <6lowpan@ietf.org>; Sun, 9 May 2010 20:19:47 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id o4A3JZLV012469 for <6lowpan@ietf.org>; Mon, 10 May 2010 12:19:35 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id o4A3JXV26932 for <6lowpan@ietf.org>; Mon, 10 May 2010 12:19:34 +0900 (JST) 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, 10 May 2010 11:20:20 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD0414DF4B@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some clarification on draft-ietf-6lowpan-usecases-05 Thread-Index: Acrv77hD2k1LfxWfQnOk4ghz1o2NGQ== From: "Mohana Jeyatharan" To: <6lowpan@ietf.org> Subject: [6lowpan] Some clarification on draft-ietf-6lowpan-usecases-05 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 03:19:58 -0000 Hi, In draft (draft-ietf-6lowpan-usecases-05), in section 3.4.1 in the home automation usecase section it is stated that the communication scenario is mostly tied between host and sinks(ER and LC) placed inside lowPAN. Does this apply to smart energy application mentioned in the draft such as DR, DSM, Peak energy pricing? If all home automation communication endpoints related to appliances are placed inside the LowPAN, then how does these functions take place(DSM, DR, Peak energy pricing). Is it assumed that DR takes place by device sending load requirement to LC/ER and then ER sending collected demand information of multiple devices to the utlity. If the draft can clearly explain these it is more useful. Also what is the benefit of having such sink in architecture for the energy management applications? Why not avoid such sinks? Thanks. BR, Mohana From erik.nordmark@oracle.com Sun May 9 23:58:54 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8255A3A6B56; Sun, 9 May 2010 23:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.335 X-Spam-Level: X-Spam-Status: No, score=-3.335 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNOFf0XueWWW; Sun, 9 May 2010 23:58:53 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 75D023A67F5; Sun, 9 May 2010 23:58:53 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4A6wad7019511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 06:58:37 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4A2bhIw023938; Mon, 10 May 2010 06:58:34 GMT Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 226605541273474688; Sun, 09 May 2010 23:58:08 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 09 May 2010 23:58:08 -0700 Message-ID: <4BE7AE79.6070608@oracle.com> Date: Sun, 09 May 2010 23:58:01 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090201.4BE7AEA1.0031:SCFMA922111,ss=1,fgs=0 Cc: Carsten Bormann , zach.shelby@sensinode.com, roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 06:58:54 -0000 On 05/ 5/10 10:38 PM, Pascal Thubert (pthubert) wrote: > Hi Carsten: > > Fact is, the latest 6LoWPAN ND draft does not support mesh under since > it lost the white board piece. I think you are mistaken. Mesh under works with just RFC 2461, since it is the layer 2 mesh that has to solve all the hard problems, essentially making things look like an Ethernet to IP. You might be confusing mesh-under with the notion of having a wired backbone be part of the lowpan without participating in the lowpan routing protocols. While I think the best way to handle such physical topologies is to make the wired backbone be part of the lowpan routing protocol domain, 6lowpan-nd carries sufficient information in the case of mesh-under for the 6LBR to track all the IPv6 addresses that are registered. > It does not support route over either since it is not compatible with > the only route over protocol in existence. Which RFC contains that 'only protocol'? ;-) I'm pretty sure I can build a route over solution using RIPv2 or OSPF which are existing IETF RFCs. It might be far from optimal, but it does indicate that the separation between the host-to-router interaction and the router-to-router is in the right place. Regards, Erik From erik.nordmark@oracle.com Mon May 10 00:03:21 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E048A3A6B61 for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 00:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.587 X-Spam-Level: X-Spam-Status: No, score=-4.587 tagged_above=-999 required=5 tests=[AWL=2.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6f-R5aR6Nkq for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 00:03:21 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id DEE7A3A6B5C for <6lowpan@ietf.org>; Mon, 10 May 2010 00:03:18 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4A735uG030451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <6lowpan@ietf.org>; Mon, 10 May 2010 07:03:06 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4A4gonc014880 for <6lowpan@ietf.org>; Mon, 10 May 2010 07:03:01 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 250396171273474889; Mon, 10 May 2010 00:01:29 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 May 2010 00:01:29 -0700 Message-ID: <4BE7AF44.30407@oracle.com> Date: Mon, 10 May 2010 00:01:24 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090204.4BE7AFAB.0035:SCFMA4539811,ss=1,fgs=0 Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 07:03:22 -0000 On 05/ 6/10 12:02 AM, Pascal Thubert (pthubert) wrote: > The RPL instance decision is end to end and matches the application > requirements. A device might send traffic over multiple instances and it > has to indicate that in the flow label. Where can I find the architectural definition of "an RPL instance"? Is it in essence akin to a VLAN on an Ethernet? This sounds like a significant departure from the existing Internet architecture. Erik From pthubert@cisco.com Mon May 10 01:26:12 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2248C28C162 for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 01:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[AWL=-3.494, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwplY1YbbeGP for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 01:26:11 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id EFC153A6B81 for <6lowpan@ietf.org>; Mon, 10 May 2010 01:24:24 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEBAL9f50uQ/uCWiWdsb2JhbACeGBUBAQEKCxERBhyiYphkhRUE X-IronPort-AV: E=Sophos;i="4.52,361,1270425600"; d="scan'208";a="7044973" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 10 May 2010 07:46:24 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4A8OC5u005976; Mon, 10 May 2010 08:24:12 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 10:24:12 +0200 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, 10 May 2010 10:24:09 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01D60B84@XMB-AMS-107.cisco.com> In-Reply-To: <4BE7AF44.30407@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: AcrwDu02vmNsVixIR+qdlO5UAjc+BgACc3MA References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> <4BE7AF44.304 07@oracl e.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , <6lowpan@ietf.org> X-OriginalArrivalTime: 10 May 2010 08:24:12.0686 (UTC) FILETIME=[2BB94AE0:01CAF01A] Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 08:26:12 -0000 Hi Erik: OSPFv3 has similar instances. Traffic Engineering is all about mapping flows of traffic onto complex topologies that are designed for those flows. So nothing real new. RPL just makes that a bit less manual, because we have harder constraints in terms of scalability and so-called autonomicity. RPL dynamically builds its TE topologies and specifies the flow label interaction a bit deeper to automate the mapping of the flows onto those topologies. I see that as extension or evolution, but not revolution. A survival trait for the Internet Architecture, really. Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Erik Nordmark > Sent: Monday, May 10, 2010 9:01 AM > To: 6lowpan@ietf.org > Subject: Re: [6lowpan] [Roll] how does a node get an IP address >=20 > On 05/ 6/10 12:02 AM, Pascal Thubert (pthubert) wrote: >=20 > > The RPL instance decision is end to end and matches the application > > requirements. A device might send traffic over multiple instances and > > it has to indicate that in the flow label. >=20 > Where can I find the architectural definition of "an RPL instance"? >=20 > Is it in essence akin to a VLAN on an Ethernet? >=20 > This sounds like a significant departure from the existing Internet > architecture. >=20 > Erik > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From erik.nordmark@oracle.com Mon May 10 01:31:44 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134F33A6B76; Mon, 10 May 2010 01:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uh5Zp4m3QV5R; Mon, 10 May 2010 01:31:43 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 4D9763A6B70; Mon, 10 May 2010 01:31:21 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4A8UxTF016605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 08:31:00 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o49L6FJ0030117; Mon, 10 May 2010 08:30:55 GMT Received: from abhmt003.oracle.com by acsmt353.oracle.com with ESMTP id 226818191273480226; Mon, 10 May 2010 01:30:26 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 May 2010 01:30:26 -0700 Message-ID: <4BE7C41E.5090407@oracle.com> Date: Mon, 10 May 2010 01:30:22 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> <4BE7AF44.30! 407@oracl e.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60B84@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01D60B84@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090209.4BE7C449.0108:SCFMA922111,ss=1,fgs=0 Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 08:31:44 -0000 On 05/10/10 01:24 AM, Pascal Thubert (pthubert) wrote: > Hi Erik: > > OSPFv3 has similar instances. How does a host know which "instance" to use in the case of OSPFv3? Why doesn't ROLL use the same mechanism? > Traffic Engineering is all about mapping flows of traffic onto complex > topologies that are designed for those flows. > > So nothing real new. RPL just makes that a bit less manual, because we > have harder constraints in terms of scalability and so-called > autonomicity. > > RPL dynamically builds its TE topologies and specifies the flow label > interaction a bit deeper to automate the mapping of the flows onto those > topologies. > > I see that as extension or evolution, but not revolution. A survival > trait for the Internet Architecture, really. If there is a need to evolve the Internet Architecture, it is best not done in a narrowly focused IETF working group. I suggest that be discussed in the INT-AREA WG to begin with. But fundamentally I don't understand why a working group like ROLL that seems keen on building small and simple networking devices at the same time feel a requirement to add bells and whistles like this. Seems to be counter to designing a simple and robust network infrastructure. Erik From abr@sdesigns.dk Mon May 10 01:42:22 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8E63A6B84; Mon, 10 May 2010 01:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7Xba4pMbFie; Mon, 10 May 2010 01:42:21 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id F0DBD3A6B87; Mon, 10 May 2010 01:42:14 -0700 (PDT) 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, 10 May 2010 10:42:02 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A12C@zensys17.zensys.local> In-Reply-To: <4BE7C41E.5090407@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: AcrwGzUS9S8W+J18TfaaDRrL4UQ09gAAVqlg References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com><4BE7AF44.30! 407@oracl e.com><6A2A459175DABE4BB11DE2026AA50A5D01D60B84@XMB-AMS-107.cisco.com> <4BE7C41E.5090407@oracl e.com> From: "Anders Brandt" To: "Erik Nordmark" Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 08:42:22 -0000 Erik, > But fundamentally I don't understand why a working group like=20 > ROLL that seems keen on building small and simple networking=20 > devices at the same time feel a requirement to add bells and=20 > whistles like this. Seems to be counter to designing a simple=20 > and robust network infrastructure. +1 - Anders > -----Original Message----- > From: 6lowpan-bounces@ietf.org=20 > [mailto:6lowpan-bounces@ietf.org] On Behalf Of Erik Nordmark > Sent: Monday, May 10, 2010 10:30 > To: Pascal Thubert (pthubert) > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: Re: [6lowpan] [Roll] how does a node get an IP address >=20 > On 05/10/10 01:24 AM, Pascal Thubert (pthubert) wrote: > > Hi Erik: > > > > OSPFv3 has similar instances. >=20 > How does a host know which "instance" to use in the case of OSPFv3? > Why doesn't ROLL use the same mechanism? >=20 > > Traffic Engineering is all about mapping flows of traffic=20 > onto complex=20 > > topologies that are designed for those flows. > > > > So nothing real new. RPL just makes that a bit less manual,=20 > because we=20 > > have harder constraints in terms of scalability and so-called=20 > > autonomicity. > > > > RPL dynamically builds its TE topologies and specifies the=20 > flow label=20 > > interaction a bit deeper to automate the mapping of the flows onto=20 > > those topologies. > > > > I see that as extension or evolution, but not revolution. A=20 > survival=20 > > trait for the Internet Architecture, really. >=20 > If there is a need to evolve the Internet Architecture, it is=20 > best not done in a narrowly focused IETF working group. >=20 > I suggest that be discussed in the INT-AREA WG to begin with. >=20 > But fundamentally I don't understand why a working group like=20 > ROLL that seems keen on building small and simple networking=20 > devices at the same time feel a requirement to add bells and=20 > whistles like this. Seems to be counter to designing a simple=20 > and robust network infrastructure. >=20 > Erik > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 From abr@sdesigns.dk Mon May 10 01:52:25 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06AA43A6B5C; Mon, 10 May 2010 01:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hHDNyskRJmZ; Mon, 10 May 2010 01:52:24 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id EF0D628C150; Mon, 10 May 2010 01:52:06 -0700 (PDT) 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, 10 May 2010 10:51:55 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A12D@zensys17.zensys.local> In-Reply-To: <4BE7AF44.30407@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: AcrwDt1TfpxTUPd6Q1W1nUaPf3lz7gADhSRw References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> <4BE7AF44.304 07@oracl e.com> From: "Anders Brandt" To: "Erik Nordmark" , <6lowpan@ietf.org>, Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 08:52:25 -0000 > Where can I find the architectural definition of "an RPL instance"? >=20 > Is it in essence akin to a VLAN on an Ethernet? It sounds like the same to me. With the difference that VLAN was created to simulate individual media over one wired infrastructure. With individual DODAGIDs this is already possible in RPL (?) If the rest of the Internet can live without this complex mechanism, why do we want to put that burden on much smaller nodes? My take is we should leave all this flow label stuff for the future if it appears that there really is a need for it. Internally RPL already has the OCP to do the same. just my $0.05 > -----Original Message----- > From: 6lowpan-bounces@ietf.org=20 > [mailto:6lowpan-bounces@ietf.org] On Behalf Of Erik Nordmark > Sent: Monday, May 10, 2010 09:01 > To: 6lowpan@ietf.org > Subject: Re: [6lowpan] [Roll] how does a node get an IP address >=20 > On 05/ 6/10 12:02 AM, Pascal Thubert (pthubert) wrote: >=20 > > The RPL instance decision is end to end and matches the application=20 > > requirements. A device might send traffic over multiple=20 > instances and=20 > > it has to indicate that in the flow label. >=20 > Where can I find the architectural definition of "an RPL instance"? >=20 > Is it in essence akin to a VLAN on an Ethernet? >=20 > This sounds like a significant departure from the existing=20 > Internet architecture. >=20 > Erik > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 From erik.nordmark@oracle.com Mon May 10 02:01:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3329F3A6B2A; Mon, 10 May 2010 02:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUNgQugjfBwf; Mon, 10 May 2010 02:01:57 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id CA5AA3A6B30; Mon, 10 May 2010 02:01:54 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4A91Zet003616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 09:01:37 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4A8k8UY001048; Mon, 10 May 2010 09:01:34 GMT Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 250664271273482093; Mon, 10 May 2010 02:01:33 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 May 2010 02:01:33 -0700 Message-ID: <4BE7CB69.5020301@oracle.com> Date: Mon, 10 May 2010 02:01:29 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Anders Brandt References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com> <4BE7AF44.30! 407@oracl e.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A12D@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A12D@zensys17.zensys.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090201.4BE7CB72.0194:SCFMA922111,ss=1,fgs=0 Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 09:01:58 -0000 On 05/10/10 01:51 AM, Anders Brandt wrote: > >> Where can I find the architectural definition of "an RPL instance"? >> >> Is it in essence akin to a VLAN on an Ethernet? > > It sounds like the same to me. With the difference that VLAN was created > to > simulate individual media over one wired infrastructure. > With individual DODAGIDs this is already possible in RPL (?) I think the terminology and use is more confused than that. The descriptions I've seen of the use of ROLL instances talk of differentiating things for the low delay vs. high throughput packets. This used to be called "ToS routing" back when OSPF supported it (I think it was removed because nobody used it.) One could envision something similar for ROLL using the Traffic Class field in the data packets, and building a separate tree for each traffic class. But Pascal referred to OSPFv3 instances, which is merely a local identifier on one link to enable multiple OSPF ships in the night sharing e.g., one Ethernet. Thus that instance ID does not span multiple router hops. That has similar effect to having the OSPF control plane run on separate VLANs on that Ethernet. The industry also seems to be using terms like routing instances for the cases when there are multiple set of interconnected (virtual) routers that e.g., provide a service for different customers. Thus ROLL could benefit from clearer terminology and staying away from the term "instances"; if it is about Traffic Class then it makes sense to call it that. > If the rest of the Internet can live without this complex mechanism, why > do > we want to put that burden on much smaller nodes? > My take is we should leave all this flow label stuff for the future if > it > appears that there really is a need for it. I have no problem keeping the first RFC of a protocol as simple as possible. If the protocol gets widely deployed one can consider extending it later. Erik From pthubert@cisco.com Mon May 10 02:07:22 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6233A681F; Mon, 10 May 2010 02:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=-3.514, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSlgPD1M8vui; Mon, 10 May 2010 02:07:21 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3E06728C15C; Mon, 10 May 2010 02:07:10 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEBABpp50uQ/uCWiWdsb2JhbACeGBUBAQEKCxERBhyjBZhtgmaCLwQ X-IronPort-AV: E=Sophos;i="4.52,361,1270425600"; d="scan'208";a="7047581" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 10 May 2010 08:29:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4A96wgS021593; Mon, 10 May 2010 09:06:58 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 11:06:57 +0200 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, 10 May 2010 11:06:53 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> In-Reply-To: <4BE7AE79.6070608@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: AcrwDjw2JQxyX+I4SZuQhkCh63xQygAC/SmQ References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , X-OriginalArrivalTime: 10 May 2010 09:06:57.0937 (UTC) FILETIME=[24BB8810:01CAF020] Cc: Carsten Bormann , 6lowpan@ietf.org, roll@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 09:07:22 -0000 Hi Erik Please see below: > I think you are mistaken. > Mesh under works with just RFC 2461, since it is the layer 2 mesh that has to > solve all the hard problems, essentially making things look like an Ethernet to > IP. [Pascal] Assumptions, assumptions. I think you're confusing the 802.11 infrastructure mode and the larger world of mesh under. You'll note that 11S does not go far trying to extend the concept to a real mesh.=20 What about other well-known mesh under topologies like Frame Relay? >=20 > You might be confusing mesh-under with the notion of having a wired > backbone be part of the lowpan without participating in the lowpan routing > protocols. While I think the best way to handle such physical topologies is to > make the wired backbone be part of the lowpan routing protocol domain, > 6lowpan-nd carries sufficient information in the case of mesh-under for the > 6LBR to track all the IPv6 addresses that are registered. [Pascal] The big question is whether the routing domain is an IGP or an SGP. If it is an IGP, then you've split the mesh into multiple mesh an eluded the question. On the way, you've lost the capability to move seamlessly and that is not acceptable. So it must be an SGP. But then it's a route-over solution, even if you're routing only in the backbone. If you do that, why not do it throughout?=20 > > It does not support route over either since it is not compatible with > > the only route over protocol in existence. >=20 > Which RFC contains that 'only protocol'? ;-) [Pascal] Please, I really wish to make progress. I do. =20 > I'm pretty sure I can build a route over solution using RIPv2 or OSPF which are > existing IETF RFCs. It might be far from optimal, but it does indicate that the > separation between the host-to-router interaction and the router-to-router > is in the right place. [Pascal] I'm pretty sure that we can extend those to make decent SGPs for networks where they are fit. They will not be fit inside the LoWPANs, though. Just figure deploying OSPF/P2MP. You'd having to set up a dominating set of routers, and then suffer the bows and arrows of outrageous multicasts. We made that study and decided to work on RPL. What they are missing is the notion of "keeping things together" which relates to the concept of root or authoritative router. Once you have this concept, it's only fair to propagate PIO and RIO as we propose to do in RPL. I do not think I am mistaken. I am certainly unclear. Let's see: The backbone router that was elected in Dublin as WG doc for 6LoWPAN ND was mostly concerned with mesh under. The idea behind was that any route-over (=3D=3D routing within the subnet) specific problem that = would come on top would have to be managed as part of the router-over solution, which we (try to) do in RPL by the way.=20 The expectation of the 6LoWPAN WG when we elected the backbone router draft over Samita's draft was to radically eliminate multicast. The backbone router draft takes a number of measures to get there. The most obvious is the use of NS/NA as a registration mechanism, and I'm very happy that this core idea is still present in the current draft, though the original author somewhat disappeared by some black magic that's quite unusual to the IETF. I claim that the current proposed solution still does not work on mesh under because it does not fulfill that expectation. For instance, I do not see how multicast is avoided in mesh under when there are more than one router in the subnet, without involving routing protocols, which would be route-over. From the backbone router draft till ND-07, we answered that question at the ND level using a whiteboard registrar as a backend to the registration. Please do not confuse that question with the use of a backbone where admittedly, either an SGP or ND proxy could work. =20 I'll add that it is pretty hard to complete the registration mechanism before we know what the registration bask end is. You demonstrated that ND-08 could not be used to front end DHCP. I demonstrated that it cannot be used to front end RPL either. And it's broken for mesh under because it is incomplete. I cannot see how the whole picture works from either this draft alone, or any combination of drafts on the works today.=20 For all I know ND 09 is broken while ND 07 was not. My suggestion to resolve the issues I see: - put the whiteboard interaction back in the base spec so the spec is standing on its own 2 feet. - let the route over problem propagation to RPL (that's the PIO/RIO propagation) - make a separate spec for the ND proxy piece. We have already text from Zach, Carsten and I that can be used Cheers, Pascal From pthubert@cisco.com Mon May 10 02:07:32 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB86F3A680A; Mon, 10 May 2010 02:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.741 X-Spam-Level: X-Spam-Status: No, score=-8.741 tagged_above=-999 required=5 tests=[AWL=1.858, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tP22m41cgovS; Mon, 10 May 2010 02:07:31 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D2EB528C165; Mon, 10 May 2010 02:07:23 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJJp50urR7Hu/2dsb2JhbACeGHGif5hthRUE X-IronPort-AV: E=Sophos;i="4.52,361,1270425600"; d="scan'208";a="254965441" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 10 May 2010 09:07:12 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4A97659005358; Mon, 10 May 2010 09:07:12 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 11:06:56 +0200 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, 10 May 2010 11:06:56 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01D60BE3@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [6lowpan] how does a node get an IP address Thread-Index: AcrwHn4EoGIbVqzWR9yWvoXmBQidhg== From: "Pascal Thubert (pthubert)" To: "Anders Brandt" , "Erik Nordmark" , <6lowpan@ietf.org>, X-OriginalArrivalTime: 10 May 2010 09:06:56.0572 (UTC) FILETIME=[23EB3FC0:01CAF020] Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 09:07:32 -0000 Anders,=20 sorry but you're confused.=20 Even if we decided to limit to one instance per OCP, then the instanceID discussion would become an OCP discussion. Cheers, Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Anders Brandt > Sent: Monday, May 10, 2010 10:52 AM > To: Erik Nordmark; 6lowpan@ietf.org; roll@ietf.org > Subject: Re: [Roll] [6lowpan] how does a node get an IP address >=20 >=20 > > Where can I find the architectural definition of "an RPL instance"? > > > > Is it in essence akin to a VLAN on an Ethernet? >=20 > It sounds like the same to me. With the difference that VLAN was created to > simulate individual media over one wired infrastructure. > With individual DODAGIDs this is already possible in RPL (?) >=20 > If the rest of the Internet can live without this complex mechanism, why do > we want to put that burden on much smaller nodes? > My take is we should leave all this flow label stuff for the future if it appears > that there really is a need for it. > Internally RPL already has the OCP to do the same. >=20 > just my $0.05 >=20 > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org > > [mailto:6lowpan-bounces@ietf.org] On Behalf Of Erik Nordmark > > Sent: Monday, May 10, 2010 09:01 > > To: 6lowpan@ietf.org > > Subject: Re: [6lowpan] [Roll] how does a node get an IP address > > > > On 05/ 6/10 12:02 AM, Pascal Thubert (pthubert) wrote: > > > > > The RPL instance decision is end to end and matches the application > > > requirements. A device might send traffic over multiple > > instances and > > > it has to indicate that in the flow label. > > > > Where can I find the architectural definition of "an RPL instance"? > > > > Is it in essence akin to a VLAN on an Ethernet? > > > > This sounds like a significant departure from the existing Internet > > architecture. > > > > Erik > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon May 10 02:21:17 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7440928C165; Mon, 10 May 2010 02:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.572 X-Spam-Level: X-Spam-Status: No, score=-7.572 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBjKpVSXp+XD; Mon, 10 May 2010 02:21:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4D25A28C187; Mon, 10 May 2010 02:19:40 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEBAGNs50uQ/uCWiWdsb2JhbACeGBUBAQEKCxERBhyid5hvhRUE X-IronPort-AV: E=Sophos;i="4.52,361,1270425600"; d="scan'208";a="60972686" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 May 2010 09:19:28 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4A9JRtT025287; Mon, 10 May 2010 09:19:28 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 11:19:17 +0200 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, 10 May 2010 11:19:14 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01D60BFB@XMB-AMS-107.cisco.com> In-Reply-To: <4BE7CB69.5020301@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: AcrwH3BKv8b/i1yvRvOOHMskETl3aAAAQEkg References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-107.cisco.com><4BE7AF44.30! 407@oracl e.com><6D9687E95918C04A8B30A7D6DA805A3E0142A12D@zensys17.zensys.local> <4BE7CB69.5020301@oracl e.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , "Anders Brandt" X-OriginalArrivalTime: 10 May 2010 09:19:17.0988 (UTC) FILETIME=[DDD65A40:01CAF021] Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 09:21:17 -0000 Hi Erik > I think the terminology and use is more confused than that. [Pascal] terminology is a actually a incredibly hard problem because all words are so overloaded already, and differently for different persons >=20 > The descriptions I've seen of the use of ROLL instances talk of differentiating > things for the low delay vs. high throughput packets. > This used to be called "ToS routing" back when OSPF supported it (I think it > was removed because nobody used it.) One could envision something similar > for ROLL using the Traffic Class field in the data packets, and building a > separate tree for each traffic class. >=20 > But Pascal referred to OSPFv3 instances, which is merely a local identifier on > one link to enable multiple OSPF ships in the night sharing e.g., one Ethernet. > Thus that instance ID does not span multiple router hops. That has similar > effect to having the OSPF control plane run on separate VLANs on that > Ethernet. [Pascal] RPL instances are exactly that: ship in the night instances operating on the same subnet, and that's why we pick the term. Obviously we extended the concept to a multilink subnet, but that's the topology we have to live with. And that's the closest abstraction we had that we could extend to the route over world.=20 You'll note that RPL instances, like OSPFv3 instances, are often but not necessarily used to map traffic classes. They are used to map flows which can have an arbitrary application meaning. One of the results of having an instance is that the edge router can have policies as to where a given instance is redistributed. For instance, VPN(s) serving metering companies. > I have no problem keeping the first RFC of a protocol as simple as possible. If > the protocol gets widely deployed one can consider extending it later. [Pascal] RPL describes the operation within one instance. For that reason, the concept does not make the spec any more complex. As opposed to ND-09, the spec stands on its own 2 feet with instance 0. The instance management for other instances is left out. Cheers, Pascal From zach@sensinode.com Mon May 10 02:55:30 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BDCA28C16A; Mon, 10 May 2010 02:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceE9Ny4jv5hl; Mon, 10 May 2010 02:55:29 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 831C828C160; Mon, 10 May 2010 02:55:17 -0700 (PDT) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4A9t0Mx015158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 May 2010 12:55:00 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> Date: Mon, 10 May 2010 12:55:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <48B43071-DC1D-4CCD-80C5-161CFC1C787C@sensinode.com> References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1077) Cc: roll@ietf.org, zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 09:55:30 -0000 Pascal, I think you're being a bit paranoid here. Let me try to correct some = misunderstandings.=20 Again, I think you are fighting yourself here with regard to prefix = dissemination. We have already agreed that nothing in nd-09 prevents RPL = from disseminating the PIOs. In fact, it specifically says that if the = routing protocol does that already, then great. Other routing protocol = might need the prefix dissemination option in nd-09, thus the spec = "stands on its own feet". So as far as the 6lowpan WG is concerned there = is nothing to discuss. It is up to the ROLL working group to discuss if = and how it wants to disseminate prefix information to RPL routers.=20 Regarding InstanceIDs and other RPL specific host issues, there is = nothing in nd-09 preventing that either. Nor can a 6lowpan document = specify something for a host to do which is RPL related. If RPL wants to = specify some ND option to be carried in RAs with regard to flow labels - = then go for it. But don't complain about ND here...=20 Regarding the extended LoWPAN functionality you are referring to below. = The WG consensus after Hiroshima was to split the ND draft into a base = draft (which was done in nd-08 already!) and a separate Extended LoWPAN = draft. As I have told you, you need to find the time to write that = extended LoWPAN draft (let's do it) and explain how to achieve these = kinds of topologies. I'm happy to help, but my hands are full right now. The WG consensus in Anaheim was to make a clean re-write of the WG = document integrating the NS/NA mechanism from nd-simple and the base = mechanism of address registration from nd-08. This is what we did. I = believe the result of this is a very good draft which specifies the = host-router interface and definitely stands on its own feet as it is = mesh-under, route-over and routing protocol independent as it should be. On May 10, 2010, at 12:06 , Pascal Thubert (pthubert) wrote: >=20 > For all I know ND 09 is broken while ND 07 was not. The WG consensus was the opposite, sorry.=20 > My suggestion to > resolve the issues I see: >=20 > - put the whiteboard interaction back in the base spec so the spec is > standing on its own 2 feet. nd-09 does have the ability to do DAD to the edge of the LoWPAN...=20 > - let the route over problem propagation to RPL (that's the PIO/RIO > propagation) It DOES!!!! Remember RPL is not *the* only routing protocol. I can = implement DYMO on a LoWPAN and it will need the prefix dissemination = method from nd-09.=20 > - make a separate spec for the ND proxy piece. We have already text = from > Zach, Carsten and I that can be used Pascal, you know very well that is your AP. This was also already = decided by the working group already after Hiroshima. Argh, Zach --=20 Zach Shelby, Head of Research, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Mon May 10 03:19:36 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0A53A6B8D; Mon, 10 May 2010 03:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.588 X-Spam-Level: X-Spam-Status: No, score=-4.588 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRVW9peS6vUg; Mon, 10 May 2010 03:19:35 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id F11D13A685A; Mon, 10 May 2010 03:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o4AAHiQ6007675; Mon, 10 May 2010 12:17:44 +0200 (CEST) Received: from [192.168.217.101] (p5489AF27.dip.t-dialin.net [84.137.175.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id D73EDD3B4; Mon, 10 May 2010 12:17:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <48B43071-DC1D-4CCD-80C5-161CFC1C787C@sensinode.com> Date: Mon, 10 May 2010 12:17:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6AA3A1B1-8BC5-4C8D-BFEA-1B239C7E8923@tzi.org> References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> <48B43071-DC1D-4CCD-80C5-161C FC1C787C@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1078) Cc: zach.shelby@sensinode.com, roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 10:19:37 -0000 On May 10, 2010, at 11:55, Zach Shelby wrote: > We have already agreed that nothing in nd-09 prevents RPL from = disseminating the PIOs. In fact, it specifically says that if the = routing protocol does that already, then great. Other routing protocol = might need the prefix dissemination option in nd-09, thus the spec = "stands on its own feet". So as far as the 6lowpan WG is concerned there = is nothing to discuss. It is up to the ROLL working group to discuss if = and how it wants to disseminate prefix information to RPL routers.=20 +1. However, please note also that a LoWPAN needs more information = disseminated than the PIOs. Unless RPL is extended to carry compression context as well, it seems = more logical to do all this network configuration dissemination in = 6LoWPAN-ND. (No, you don't *need* compression context in a LoWPAN, but it gets = significantly less efficient without it. And it breaks spectacularly if the compression context gets inconsistent = between nodes.) Both compression context and prefix information is likely to change on = relatively slow timescales (days/weeks), which is another reason why it = seems appropriate to use a configuration protocol for the dissemination = of both, rather than a routing protocol operating in terms of = seconds/minutes. Gruesse, Carsten From pthubert@cisco.com Mon May 10 03:39:22 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060D73A6B92; Mon, 10 May 2010 03:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.791 X-Spam-Level: X-Spam-Status: No, score=-8.791 tagged_above=-999 required=5 tests=[AWL=1.808, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCNJYCUX2HNd; Mon, 10 May 2010 03:39:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C527B28C166; Mon, 10 May 2010 03:39:16 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKt+50urR7H+/2dsb2JhbACeGHGiZJh/hRUE X-IronPort-AV: E=Sophos;i="4.52,361,1270425600"; d="scan'208";a="324543655" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 10 May 2010 10:39:05 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4AAciKn021627; Mon, 10 May 2010 10:39:05 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 12:39:03 +0200 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, 10 May 2010 12:38:59 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01D60CB1@XMB-AMS-107.cisco.com> In-Reply-To: <48B43071-DC1D-4CCD-80C5-161CFC1C787C@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: AcrwJuFGic5jRZZBTASnNfTLdU3XogAAyTLQ References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> <48B43071-DC1D-4CCD-80C5-161C FC1C787C @sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" X-OriginalArrivalTime: 10 May 2010 10:39:03.0513 (UTC) FILETIME=[023B8490:01CAF02D] Cc: roll@ietf.org, zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 10:39:22 -0000 Zach, You're not addressing my question. My question is how do you do mesh under with 2 routers and the answer cannot be route over. So? If the draft does not answer that question and cannot point on a draft that does, then, no, it does not stand on its feet, sorry. The vote that lead to 08 was based on the assumption that we could make a front end that could be common to multiple backend techniques, DHCP, whiteboard, etc... This assumption was wrong. Erik demonstrated that it already failed with DHCP before we even tried to make it work for whiteboard. So it's simply moot. I think the draft needs the complete picture and that includes the registrar.=20 The desire to separate the ND proxy piece is different because there are alternate ways like an SGP over the backbone, so I understand that split a lot better. The whiteboard is not tied with the ND proxy. It comes with mesh under as a solution to resolve a device address and do DAD. Something that the router registration cannot do as soon as you have 2 routers. Finally, I've not seen a consensus to rewrite ND from 08 to what it is today. I've seen Geoff at the mike in favor, and you saying don't worry I'll work with the author of ND simple and sort that out. Hardly a consensus to me. Anyway, I consider the outcome, think that you could have sorted better, and propose ins and outs. If you're so sure you don't need feedback, just ignore it. Cheers, Pascal > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com] > Sent: Monday, May 10, 2010 11:55 AM > To: Pascal Thubert (pthubert) > Cc: Erik Nordmark; zach.shelby@sensinode.com; 6lowpan@ietf.org; > roll@ietf.org > Subject: Re: [6lowpan] [Roll] how does a node get an IP address >=20 > Pascal, >=20 > I think you're being a bit paranoid here. Let me try to correct some > misunderstandings. >=20 > Again, I think you are fighting yourself here with regard to prefix > dissemination. We have already agreed that nothing in nd-09 prevents RPL > from disseminating the PIOs. In fact, it specifically says that if the routing > protocol does that already, then great. Other routing protocol might need > the prefix dissemination option in nd-09, thus the spec "stands on its own > feet". So as far as the 6lowpan WG is concerned there is nothing to discuss. It > is up to the ROLL working group to discuss if and how it wants to disseminate > prefix information to RPL routers. >=20 > Regarding InstanceIDs and other RPL specific host issues, there is nothing in > nd-09 preventing that either. Nor can a 6lowpan document specify > something for a host to do which is RPL related. If RPL wants to specify some > ND option to be carried in RAs with regard to flow labels - then go for it. But > don't complain about ND here... >=20 > Regarding the extended LoWPAN functionality you are referring to below. > The WG consensus after Hiroshima was to split the ND draft into a base draft > (which was done in nd-08 already!) and a separate Extended LoWPAN draft. > As I have told you, you need to find the time to write that extended LoWPAN > draft (let's do it) and explain how to achieve these kinds of topologies. I'm > happy to help, but my hands are full right now. >=20 > The WG consensus in Anaheim was to make a clean re-write of the WG > document integrating the NS/NA mechanism from nd-simple and the base > mechanism of address registration from nd-08. This is what we did. I believe > the result of this is a very good draft which specifies the host-router interface > and definitely stands on its own feet as it is mesh-under, route-over and > routing protocol independent as it should be. >=20 > On May 10, 2010, at 12:06 , Pascal Thubert (pthubert) wrote: > > > > For all I know ND 09 is broken while ND 07 was not. >=20 > The WG consensus was the opposite, sorry. >=20 > > My suggestion to > > resolve the issues I see: > > > > - put the whiteboard interaction back in the base spec so the spec is > > standing on its own 2 feet. >=20 > nd-09 does have the ability to do DAD to the edge of the LoWPAN... >=20 > > - let the route over problem propagation to RPL (that's the PIO/RIO > > propagation) >=20 > It DOES!!!! Remember RPL is not *the* only routing protocol. I can > implement DYMO on a LoWPAN and it will need the prefix dissemination > method from nd-09. >=20 > > - make a separate spec for the ND proxy piece. We have already text > > from Zach, Carsten and I that can be used >=20 > Pascal, you know very well that is your AP. This was also already decided by > the working group already after Hiroshima. >=20 > Argh, > Zach >=20 > -- > Zach Shelby, Head of Research, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 From zach@sensinode.com Mon May 10 04:13:08 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897733A6B88 for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 04:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6RsBoB8jFfG for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 04:13:07 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D8AF33A6B91 for <6lowpan@ietf.org>; Mon, 10 May 2010 04:12:52 -0700 (PDT) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4ABCY0X012156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 May 2010 14:12:34 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01D60CB1@XMB-AMS-107.cisco.com> Date: Mon, 10 May 2010 14:12:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> <48B43071-DC1D-4CCD-80C5-161! CFC1C787C @sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60CB1@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1077) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 11:13:08 -0000 (now limited to the 6lowpan list) On May 10, 2010, at 13:38 , Pascal Thubert (pthubert) wrote: > Zach, >=20 > You're not addressing my question. My question is how do you do mesh > under with 2 routers and the answer cannot be route over. So? > If the draft does not answer that question and cannot point on a draft > that does, then, no, it does not stand on its feet, sorry. This configuration is clearly out-of-scope for the base mechanism draft = (nd-09). When you write that=20 extended LoWPAN draft then there is something to reference. Anyways, = mesh-under just a special case=20 of route-over where all LoWPAN nodes happen to be hosts one IP hop away = from the 6LBR. One=20 solution is to run a routing protocol over the backbone as with = route-over to solve this. >=20 > The vote that lead to 08 was based on the assumption that we could = make > a front end that could be common to multiple backend techniques, DHCP, > whiteboard, etc... > This assumption was wrong. Erik demonstrated that it already failed = with > DHCP before we even tried to make it work for whiteboard. So it's > simply moot. I think the draft needs the complete picture and that > includes the registrar.=20 DHCPv6 works just fine with nd-09. Let's write the extended LoWPAN draft = first=20 before saying that nd-09 is broken. What exactly are you missing here = from nd-09,=20 is there some specific option or codes or what that would be needed by = your upcoming draft? > The desire to separate the ND proxy piece is different because there = are > alternate ways like an SGP over the backbone, so I understand that = split > a lot better. The whiteboard is not tied with the ND proxy. It comes > with mesh under as a solution to resolve a device address and do DAD. > Something that the router registration cannot do as soon as you have 2 > routers. Nor do we claim it does that in the nd-09 draft. Of course if you want = to enable DAD to the edge with multiple routers advertising the same = prefix(es) then you somehow need to synchronize the DAD tables between = routers. How to do this is out of scope for nd-09 in my opinion, it = belongs in some other draft or is implementation specific.=20 > Finally, I've not seen a consensus to rewrite ND from 08 to what it is > today. I've seen Geoff at the mike in favor, and you saying don't = worry > I'll work with the author of ND simple and sort that out. Hardly a > consensus to me. Anyway, I consider the outcome, think that you could > have sorted better, and propose ins and outs. If you're so sure you > don't need feedback, just ignore it. Come on, this is more like general complaining about the WG direction = than comments on this draft. We are happy to listen to draft comments, = but then let's make them on the draft under its assumptions. WG = direction is an issue for the chairs...=20 Zach >=20 > Cheers, >=20 > Pascal >=20 >=20 >> -----Original Message----- >> From: Zach Shelby [mailto:zach@sensinode.com] >> Sent: Monday, May 10, 2010 11:55 AM >> To: Pascal Thubert (pthubert) >> Cc: Erik Nordmark; zach.shelby@sensinode.com; 6lowpan@ietf.org; >> roll@ietf.org >> Subject: Re: [6lowpan] [Roll] how does a node get an IP address >>=20 >> Pascal, >>=20 >> I think you're being a bit paranoid here. Let me try to correct some >> misunderstandings. >>=20 >> Again, I think you are fighting yourself here with regard to prefix >> dissemination. We have already agreed that nothing in nd-09 prevents > RPL >> from disseminating the PIOs. In fact, it specifically says that if = the > routing >> protocol does that already, then great. Other routing protocol might > need >> the prefix dissemination option in nd-09, thus the spec "stands on = its > own >> feet". So as far as the 6lowpan WG is concerned there is nothing to > discuss. It >> is up to the ROLL working group to discuss if and how it wants to > disseminate >> prefix information to RPL routers. >>=20 >> Regarding InstanceIDs and other RPL specific host issues, there is > nothing in >> nd-09 preventing that either. Nor can a 6lowpan document specify >> something for a host to do which is RPL related. If RPL wants to > specify some >> ND option to be carried in RAs with regard to flow labels - then go > for it. But >> don't complain about ND here... >>=20 >> Regarding the extended LoWPAN functionality you are referring to > below. >> The WG consensus after Hiroshima was to split the ND draft into a = base > draft >> (which was done in nd-08 already!) and a separate Extended LoWPAN > draft. >> As I have told you, you need to find the time to write that extended > LoWPAN >> draft (let's do it) and explain how to achieve these kinds of > topologies. I'm >> happy to help, but my hands are full right now. >>=20 >> The WG consensus in Anaheim was to make a clean re-write of the WG >> document integrating the NS/NA mechanism from nd-simple and the base >> mechanism of address registration from nd-08. This is what we did. I > believe >> the result of this is a very good draft which specifies the > host-router interface >> and definitely stands on its own feet as it is mesh-under, route-over > and >> routing protocol independent as it should be. >>=20 >> On May 10, 2010, at 12:06 , Pascal Thubert (pthubert) wrote: >>>=20 >>> For all I know ND 09 is broken while ND 07 was not. >>=20 >> The WG consensus was the opposite, sorry. >>=20 >>> My suggestion to >>> resolve the issues I see: >>>=20 >>> - put the whiteboard interaction back in the base spec so the spec > is >>> standing on its own 2 feet. >>=20 >> nd-09 does have the ability to do DAD to the edge of the LoWPAN... >>=20 >>> - let the route over problem propagation to RPL (that's the PIO/RIO >>> propagation) >>=20 >> It DOES!!!! Remember RPL is not *the* only routing protocol. I can >> implement DYMO on a LoWPAN and it will need the prefix dissemination >> method from nd-09. >>=20 >>> - make a separate spec for the ND proxy piece. We have already text >>> from Zach, Carsten and I that can be used >>=20 >> Pascal, you know very well that is your AP. This was also already > decided by >> the working group already after Hiroshima. >>=20 >> Argh, >> Zach >>=20 >> -- >> Zach Shelby, Head of Research, Sensinode Ltd. >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >> Mobile: +358 40 7796297 >=20 --=20 Zach Shelby, Head of Research, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From pthubert@cisco.com Mon May 10 04:44:45 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232CB28C17B for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 04:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.081 X-Spam-Level: X-Spam-Status: No, score=-8.081 tagged_above=-999 required=5 tests=[AWL=1.029, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTc66eSDbEX8 for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 04:44:44 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 2727128C17E for <6lowpan@ietf.org>; Mon, 10 May 2010 04:44:27 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJyO50urR7H+/2dsb2JhbACeHnGiVZkIhRQE X-IronPort-AV: E=Sophos;i="4.52,361,1270425600"; d="scan'208";a="195097592" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 10 May 2010 11:44:15 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4ABhia1004613; Mon, 10 May 2010 11:44:14 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 13:43:56 +0200 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, 10 May 2010 13:43:53 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01D60D34@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: AcrwMbWa+56Id5okS9e24YC4sAyJKgAAblNg References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> <48B43071-DC1D-4CCD-80C5-161! CFC1C78 7C @sensinod e.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60CB1@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" X-OriginalArrivalTime: 10 May 2010 11:43:56.0257 (UTC) FILETIME=[127D1D10:01CAF036] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 11:44:45 -0000 Hi Zach > > > You're not addressing my question. My question is how do you do mesh > > under with 2 routers and the answer cannot be route over. So? > > If the draft does not answer that question and cannot point on a draft > > that does, then, no, it does not stand on its feet, sorry. >=20 > This configuration is clearly out-of-scope for the base mechanism draft (nd- > 09). When you write that extended LoWPAN draft then there is something to > reference. Anyways, mesh-under just a special case of route-over where all > LoWPAN nodes happen to be hosts one IP hop away from the 6LBR. One > solution is to run a routing protocol over the backbone as with route-over to > solve this. [Pascal] I think that we agree. If a mesh-under network where nodes are not one hop away from an LBR is out of scope, then the draft works fine. To be able to accommodate more than 1 router in the mesh-under network, we need either route over, or the registrar we called the whiteboard. In previous understanding, a LoWPAN would be extended via a backbone, and I expected a different, faster technology there.=20 If we take away the WB from the base spec, then an LoWPAN becomes extended as soon as we add a second router onto it. Would that be your new definition?=20 > > The vote that lead to 08 was based on the assumption that we could make > > a front end that could be common to multiple backend techniques, DHCP, > > whiteboard, etc... > > This assumption was wrong. Erik demonstrated that it already failed with > > DHCP before we even tried to make it work for whiteboard. So it's > > simply moot. I think the draft needs the complete picture and that > > includes the registrar. >=20 > DHCPv6 works just fine with nd-09. Let's write the extended LoWPAN draft > first > before saying that nd-09 is broken. What exactly are you missing here from > nd-09, > is there some specific option or codes or what that would be needed by your > upcoming draft? >=20 [Pascal] My other point exactly. We do not know till we have the other Draft. I thought having the WB inside the base spec would avoid that hassle. But obviously we can have 2 specs pointing on one another. Or 3, since I figure that the ND proxy is really a separate beast.=20 What does the group think? Pascal From erik.nordmark@oracle.com Mon May 10 04:47:02 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE80E3A68AA; Mon, 10 May 2010 04:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[AWL=1.805, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeEl6CwFzi4l; Mon, 10 May 2010 04:47:02 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id C676F3A68DA; Mon, 10 May 2010 04:46:51 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4ABkYKZ016618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 11:46:36 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4A3l7Af009118; Mon, 10 May 2010 11:46:33 GMT Received: from abhmt003.oracle.com by acsmt353.oracle.com with ESMTP id 227292661273491940; Mon, 10 May 2010 04:45:40 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 May 2010 04:45:40 -0700 Message-ID: <4BE7F1DC.1060206@oracle.com> Date: Mon, 10 May 2010 04:45:32 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> <48B43071-DC1D-4CCD-80C5-161! CFC1C787C @sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60CB1@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01D60CB1@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090203.4BE7F21E.012E:SCFMA922111,ss=1,fgs=0 Cc: roll@ietf.org, 6lowpan@ietf.org, zach.shelby@sensinode.com Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 11:47:02 -0000 On 05/10/10 03:38 AM, Pascal Thubert (pthubert) wrote: > Zach, > > You're not addressing my question. My question is how do you do mesh > under with 2 routers and the answer cannot be route over. So? > If the draft does not answer that question and cannot point on a draft > that does, then, no, it does not stand on its feet, sorry. Are you talking about having two 6LBRs? Or is this a concern about the wired backbone? Please be specific. For the case of two 6LBRs it is done the same way as having two routers on an Ethernet: both routers are configured with the same prefix(es) which will be advertised in the Router Advertisements. The only added thing in 6lowpan-nd is the Context option for header compression. That implies that the two routers need to be configured with the same compression information. Note that the hosts will register with both of the routers, hence both have the full information about all the hosts. What do you see as missing in 6lowpan-nd-09 for the case of 6LBRs? Erik From cabo@tzi.org Mon May 10 05:13:14 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 734A828C18F for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 05:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.455 X-Spam-Level: X-Spam-Status: No, score=-4.455 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDh+f9dfSu85 for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 05:13:09 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 945E83A68EA for <6lowpan@ietf.org>; Mon, 10 May 2010 05:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o4ACCiik029122 for <6lowpan@ietf.org>; Mon, 10 May 2010 14:12:44 +0200 (CEST) Received: from [192.168.217.101] (p5489AF27.dip.t-dialin.net [84.137.175.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id F0807D4C2; Mon, 10 May 2010 14:12:43 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 10 May 2010 14:12:42 +0200 To: 6lowpan@ietf.org Message-Id: <2443F5CC-9591-475B-9E69-B86944E7CAE3@tzi.org> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [6lowpan] Question of the week: ND-09 status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 12:13:14 -0000 >> I've not seen a consensus to rewrite ND from 08 to what it is >> today. I've seen Geoff at the mike in favor, and you saying don't = worry >> I'll work with the author of ND simple and sort that out. Hardly a >> consensus to me. >=20 > WG direction is an issue for the chairs...=20 Well, no, this is an issue for the WG. There was some vocal opposition to the complexity of ND-08. Since I was = a co-author of ND-08, I wasn't in a position to judge consensus as a WG = chair, but if I had been, I would have said very, very rough consensus = at best. I didn't co-author ND-09. I do think personally that ND-09 is in = reasonable shape, and I haven't heard strong technical arguments against = it. With the exception of Pascal, all ND-08 authors seem to like it = (even though each of us probably would do some little thing in a = different way). But, very importantly, this is not a = paste-over-the-disagreements compromise solution: It is a solid redesign = based on some evolved assumptions on what the base 6LoWPAN-ND protocol = has to do and what not. Now my questions to the WG: 1) Are these evolved assumptions correct? The most important change is that the assumption is now that we can = fully rely*) on the uniqueness of EUI-64 identifiers. Another assumption is that staying as close to the formats of RFC 4861 = as possible is a good thing. 2) Is the protocol defined in ND-09 successfully solving the problem? If the above assumptions are correct, is ND-09 the right protocol? Does = it work? If you think that additional functions such as backbone router, or = possibly using DHCP servers for certain configuration functions, are = needed: can these be added as separate documents**), with hosts = implementing just ND-09 still working correctly? 3) Is the document that is ND-09 good enough? Does it define the protocol unambiguously? Is the terminology acceptable? I would like the WG to make some progress on these questions this week. Please speak up. Gruesse, Carsten *) [=46rom my personal point of view, this is mainly burden-shifting to = the commissioning/security process, but it is not unreasonable to do = so.] **) [Yes, it would be nice to have these documents, to make sure we = understand fully how they fit together with ND. But I don't think we = have to wait for all of them.] From pthubert@cisco.com Mon May 10 05:44:56 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605F728C1E5; Mon, 10 May 2010 05:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.845 X-Spam-Level: X-Spam-Status: No, score=-8.845 tagged_above=-999 required=5 tests=[AWL=1.754, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb3A3iesN7q3; Mon, 10 May 2010 05:44:55 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id ACC4028C1AC; Mon, 10 May 2010 05:41:59 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADOc50utJV2b/2dsb2JhbACeHnGifpkEhRQE X-IronPort-AV: E=Sophos;i="4.52,362,1270425600"; d="scan'208";a="109649585" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 10 May 2010 12:41:47 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o4ACfhRw010206; Mon, 10 May 2010 12:41:47 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 14:41:44 +0200 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, 10 May 2010 14:41:41 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01D60D88@XMB-AMS-107.cisco.com> In-Reply-To: <4BE7F1DC.1060206@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: AcrwNnbpIPXcIzbRROeMnODCftt7owAAwBHw References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> <48B43071-DC1D-4CCD-80C5-161! CFC1C787C @sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60CB1@XMB-AMS-107.cisco.com> <4BE7F1DC.10 60206@or acle.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" X-OriginalArrivalTime: 10 May 2010 12:41:44.0503 (UTC) FILETIME=[25B97470:01CAF03E] Cc: roll@ietf.org, 6lowpan@ietf.org, zach.shelby@sensinode.com Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 10 May 2010 12:44:56 -0000 Hi Erik: I think Zach and I came up with a common understanding. My concern had not to do with a backbone. It has to do with 2 routers in a same mesh under topology, and without the assumption that any node can reach any other node using the mesh under technology. To illustrate this, say you use the ND base draft in a Frame Relay network. You build a hub and spoke with the router at the hub. The router is at a central office, and there are DTEs at the branch office. I agree, the draft works great! The router can resolve any incoming packet because it has a proactive registration for it. Then we want to place a second router. We place a switch between those and we split the DLCIs in half between the routers. So each of the routers get half of the registrations. There is simply no DLCI for the hosts to register to the other router.=20 In a same fashion, you do not want a node to register to all routers and receive multicast from all routers in a LoWPAN that grows to the thousands. =20 So with the draft alone, if router 1 gets a packet for a node attached to router B, the registration does not help. So the router will either multicast, which we wanted to avoid, or drop. That's my concern, that's why I've been telling you it was broken for mesh under. Zach and I agreed we could resolve this question by saying that 2 routers is already an extended LoWPAN, that will be addressed by the spec left to be done. Would you agree with that resolution? Continuing on the FR image, the deployment may choose either: - route over. define an OSPFv3 instance and connect those 2 routers as P2MP. Describing this is sort of operation out of scope for 6LoWPAN. - whiteboard. Both routers write onto the subnet white board which nodes they own, and let the mesh under figure out how they can reach one another, can be using PVC or calling out an SVC... This would be what extended does. Extending further the model, it can either: - larger route over. Extend your OSPFv3 instance in P2MP mode, or setup a number of them if you need to meet different needs, and we end up with something similar to what RPL does. - proxy ND. This can be done for specific topologies, like trees, or in the simplest expression, a backbone link, that would be point to point between 2 routers or a fully meshed core, wherever multicast can be emulated at a reasonable cost. Just like ND itself, ND proxy model seems more appropriate for transit networks than for NBMA.=20 I hope it's clearer now, Pascal > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@oracle.com] > Sent: Monday, May 10, 2010 1:46 PM > To: Pascal Thubert (pthubert) > Cc: Zach Shelby; zach.shelby@sensinode.com; 6lowpan@ietf.org; > roll@ietf.org > Subject: Re: [6lowpan] [Roll] how does a node get an IP address >=20 > On 05/10/10 03:38 AM, Pascal Thubert (pthubert) wrote: > > Zach, > > > > You're not addressing my question. My question is how do you do mesh > > under with 2 routers and the answer cannot be route over. So? > > If the draft does not answer that question and cannot point on a draft > > that does, then, no, it does not stand on its feet, sorry. >=20 > Are you talking about having two 6LBRs? > Or is this a concern about the wired backbone? Please be specific. >=20 > For the case of two 6LBRs it is done the same way as having two routers on > an Ethernet: both routers are configured with the same prefix(es) which will > be advertised in the Router Advertisements. >=20 > The only added thing in 6lowpan-nd is the Context option for header > compression. That implies that the two routers need to be configured with > the same compression information. >=20 > Note that the hosts will register with both of the routers, hence both have > the full information about all the hosts. >=20 > What do you see as missing in 6lowpan-nd-09 for the case of 6LBRs? >=20 > Erik From d.sturek@att.net Mon May 10 06:34:38 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13FB3A6937 for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 06:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0-+DF3PEotZ for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 06:34:38 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 129E53A693F for <6lowpan@ietf.org>; Mon, 10 May 2010 06:34:38 -0700 (PDT) Received: (qmail 45698 invoked from network); 10 May 2010 13:34:24 -0000 Received: from Studio (d.sturek@209.203.104.177 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 10 May 2010 06:34:24 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: OmSsyWcVM1mM7wA5KiWm0ViF4U_aElRV0h_aRxjYfLB5XDlq6L_tUk5zJsb0y2UHI3ZmDjIuHET4s6t5yBF7yZVrvcRk1QcDubesWmSoyxD9r5IGXsigo3p1gShQbdH5_I.3jZKxjt.eYb7Buq2rIWnGZiCpXQQPeGwGVDkrxbZzkJLhHjtG5YV8YE_jEV11nt5GumfaMFszBFN608Yr1nvdhDwUuWzt6Oct0ojtMPcebJ8G1oKtSgJZ2AyO__OnEwG4ju1XOMlVVrnzTVwFk7y_yy6eRAh9XjBsYtVMyIFBX.Q.nB8- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Carsten Bormann'" , <6lowpan@ietf.org> References: <2443F5CC-9591-475B-9E69-B86944E7CAE3@tzi.org> In-Reply-To: <2443F5CC-9591-475B-9E69-B86944E7CAE3@tzi.org> Date: Mon, 10 May 2010 06:34:21 -0700 Message-ID: <005901caf045$7ff40a70$7fdc1f50$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrwOihlZHtMXrUjR7Cd8+RgKshRFgACyBMw Content-Language: en-us Subject: Re: [6lowpan] Question of the week: ND-09 status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 13:34:39 -0000 I agree completely with Carsten on this. It is NOT up to the WG chairs to determine direction or consensus. It is up to the WG. I am in favor of ND-09. We should have some implementation experience shortly but it does appear to address the stated issues to ND-08 and appears to be a solid basis for 6LowPAN ND. Don -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Monday, May 10, 2010 5:13 AM To: 6lowpan@ietf.org Subject: [6lowpan] Question of the week: ND-09 status >> I've not seen a consensus to rewrite ND from 08 to what it is >> today. I've seen Geoff at the mike in favor, and you saying don't worry >> I'll work with the author of ND simple and sort that out. Hardly a >> consensus to me. > > WG direction is an issue for the chairs... Well, no, this is an issue for the WG. There was some vocal opposition to the complexity of ND-08. Since I was a co-author of ND-08, I wasn't in a position to judge consensus as a WG chair, but if I had been, I would have said very, very rough consensus at best. I didn't co-author ND-09. I do think personally that ND-09 is in reasonable shape, and I haven't heard strong technical arguments against it. With the exception of Pascal, all ND-08 authors seem to like it (even though each of us probably would do some little thing in a different way). But, very importantly, this is not a paste-over-the-disagreements compromise solution: It is a solid redesign based on some evolved assumptions on what the base 6LoWPAN-ND protocol has to do and what not. Now my questions to the WG: 1) Are these evolved assumptions correct? The most important change is that the assumption is now that we can fully rely*) on the uniqueness of EUI-64 identifiers. Another assumption is that staying as close to the formats of RFC 4861 as possible is a good thing. 2) Is the protocol defined in ND-09 successfully solving the problem? If the above assumptions are correct, is ND-09 the right protocol? Does it work? If you think that additional functions such as backbone router, or possibly using DHCP servers for certain configuration functions, are needed: can these be added as separate documents**), with hosts implementing just ND-09 still working correctly? 3) Is the document that is ND-09 good enough? Does it define the protocol unambiguously? Is the terminology acceptable? I would like the WG to make some progress on these questions this week. Please speak up. Gruesse, Carsten *) [From my personal point of view, this is mainly burden-shifting to the commissioning/security process, but it is not unreasonable to do so.] **) [Yes, it would be nice to have these documents, to make sure we understand fully how they fit together with ND. But I don't think we have to wait for all of them.] _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From d.sturek@att.net Mon May 10 06:41:53 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F161F3A6968 for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 06:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.681 X-Spam-Level: X-Spam-Status: No, score=0.681 tagged_above=-999 required=5 tests=[AWL=-0.918, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dcmGi1D2XMw for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 06:41:52 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id CDEF23A6972 for <6lowpan@ietf.org>; Mon, 10 May 2010 06:41:51 -0700 (PDT) Received: (qmail 31993 invoked from network); 10 May 2010 13:41:39 -0000 Received: from 209-203-104-177.static.twtelecom.net (d.sturek@209.203.104.177 with login) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 10 May 2010 06:41:39 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: Iot7ApUVM1nfWnyGgEWuuxrbhH1fnMnrqX01W6bP.iUDFPQBQPISuQRkH_3P6Z7Cu1RUZ34dw29qwR6tBagCJlfTqsne1.1ev1vy01Bes0ExNXWKkK1iEt6bsSsRaAZCRyiDwMeNy3vpzB0lQbFPnyei9NQkHkwyVzGDs7OOz7Rqr.VmBMWLwucGI2_ZoQv0NRlb9bI_GVaDeqYH0zQj0DdRktievUn3J48ynEdn4quUgztC_LX2cTPyyXI4MliTgNu7kAVyrl81pETKa46eFF9XMDmgeSJtuG2nlu9lVHYt7d7VTWw- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Pascal Thubert \(pthubert\)'" , "'Erik Nordmark'" , References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> Date: Mon, 10 May 2010 06:41:36 -0700 Message-ID: <005a01caf046$8366a680$8a33f380$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrwDjw2JQxyX+I4SZuQhkCh63xQygAC/SmQAAsKcWA= Content-Language: en-us Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 13:41:53 -0000 Hi Pascal, Everything you wrote below on ND-09 IS THE EXACT OPPOSITE of the WG consensus from Anaheim. Did you attend the 6LowPAN Anaheim session? Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Monday, May 10, 2010 2:07 AM To: Erik Nordmark; zach.shelby@sensinode.com Cc: 6lowpan@ietf.org; roll@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IP address Hi Erik Please see below: > I think you are mistaken. > Mesh under works with just RFC 2461, since it is the layer 2 mesh that has to > solve all the hard problems, essentially making things look like an Ethernet to > IP. [Pascal] Assumptions, assumptions. I think you're confusing the 802.11 infrastructure mode and the larger world of mesh under. You'll note that 11S does not go far trying to extend the concept to a real mesh. What about other well-known mesh under topologies like Frame Relay? > > You might be confusing mesh-under with the notion of having a wired > backbone be part of the lowpan without participating in the lowpan routing > protocols. While I think the best way to handle such physical topologies is to > make the wired backbone be part of the lowpan routing protocol domain, > 6lowpan-nd carries sufficient information in the case of mesh-under for the > 6LBR to track all the IPv6 addresses that are registered. [Pascal] The big question is whether the routing domain is an IGP or an SGP. If it is an IGP, then you've split the mesh into multiple mesh an eluded the question. On the way, you've lost the capability to move seamlessly and that is not acceptable. So it must be an SGP. But then it's a route-over solution, even if you're routing only in the backbone. If you do that, why not do it throughout? > > It does not support route over either since it is not compatible with > > the only route over protocol in existence. > > Which RFC contains that 'only protocol'? ;-) [Pascal] Please, I really wish to make progress. I do. > I'm pretty sure I can build a route over solution using RIPv2 or OSPF which are > existing IETF RFCs. It might be far from optimal, but it does indicate that the > separation between the host-to-router interaction and the router-to-router > is in the right place. [Pascal] I'm pretty sure that we can extend those to make decent SGPs for networks where they are fit. They will not be fit inside the LoWPANs, though. Just figure deploying OSPF/P2MP. You'd having to set up a dominating set of routers, and then suffer the bows and arrows of outrageous multicasts. We made that study and decided to work on RPL. What they are missing is the notion of "keeping things together" which relates to the concept of root or authoritative router. Once you have this concept, it's only fair to propagate PIO and RIO as we propose to do in RPL. I do not think I am mistaken. I am certainly unclear. Let's see: The backbone router that was elected in Dublin as WG doc for 6LoWPAN ND was mostly concerned with mesh under. The idea behind was that any route-over (== routing within the subnet) specific problem that would come on top would have to be managed as part of the router-over solution, which we (try to) do in RPL by the way. The expectation of the 6LoWPAN WG when we elected the backbone router draft over Samita's draft was to radically eliminate multicast. The backbone router draft takes a number of measures to get there. The most obvious is the use of NS/NA as a registration mechanism, and I'm very happy that this core idea is still present in the current draft, though the original author somewhat disappeared by some black magic that's quite unusual to the IETF. I claim that the current proposed solution still does not work on mesh under because it does not fulfill that expectation. For instance, I do not see how multicast is avoided in mesh under when there are more than one router in the subnet, without involving routing protocols, which would be route-over. From the backbone router draft till ND-07, we answered that question at the ND level using a whiteboard registrar as a backend to the registration. Please do not confuse that question with the use of a backbone where admittedly, either an SGP or ND proxy could work. I'll add that it is pretty hard to complete the registration mechanism before we know what the registration bask end is. You demonstrated that ND-08 could not be used to front end DHCP. I demonstrated that it cannot be used to front end RPL either. And it's broken for mesh under because it is incomplete. I cannot see how the whole picture works from either this draft alone, or any combination of drafts on the works today. For all I know ND 09 is broken while ND 07 was not. My suggestion to resolve the issues I see: - put the whiteboard interaction back in the base spec so the spec is standing on its own 2 feet. - let the route over problem propagation to RPL (that's the PIO/RIO propagation) - make a separate spec for the ND proxy piece. We have already text from Zach, Carsten and I that can be used Cheers, Pascal _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From soohongp@gmail.com Mon May 10 23:05:32 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98FFF3A6AE0 for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 23:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CE4Ze9LmVhiA for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 23:05:31 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 127643A6AD4 for <6lowpan@ietf.org>; Mon, 10 May 2010 23:05:30 -0700 (PDT) Received: by gwaa12 with SMTP id a12so2608172gwa.31 for <6lowpan@ietf.org>; Mon, 10 May 2010 23:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=oUmnR52nOFlP5Cl/YUILW7X4LIaMkYTouGJBHYfGfio=; b=sYfmRz/1VJrTpvZ3RFEBjiAUY2uwAnRMoTzxxLMM88iIaVHNj5rrAFfA2n5lC8EeR2 MgTfj8aNWbSYGlSKuGwX/DX4V8WrtzWO26Pzqt7GZgI++otyyobyn7ewFJPHpsEqQoo/ 5y29qdppR/pw96V+BTAE6QBmU8BrYPEqdUmss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=K7NB0tfspmOH+svxM5IAfyTh+s4yzvvjpQYZTjxJYm7Fk/nfitaqza+e7q1jUIRxZn 8yUDZ4TBwW2dozSosEipD2eCmt2wyR1KCKrb2v1Zkbut2RcTajZ4Bh2DBSa/5GTgNgwg B7kTLtPizhZ5ylvo4HkvN2yLORAHhmRauvp+w= MIME-Version: 1.0 Received: by 10.231.79.196 with SMTP id q4mr2987621ibk.69.1273557916264; Mon, 10 May 2010 23:05:16 -0700 (PDT) Received: by 10.231.33.138 with HTTP; Mon, 10 May 2010 23:05:16 -0700 (PDT) Date: Tue, 11 May 2010 15:05:16 +0900 Message-ID: From: Daniel Park To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=001485eaffd8332ed904864b4f4e Subject: [6lowpan] non-technical, but good news to 6lowpanner X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 11 May 2010 06:05:32 -0000 --001485eaffd8332ed904864b4f4e Content-Type: text/plain; charset=ISO-8859-1 Folks, long time no see in IETF. I'd forward a good news to 6lowpanner. Our colleagues in 6lowpan WG got merried. Eunah and Dominik. http://home.simula.no/~kaspar/wedding/ch/index.php They are also good contributors to 6lowpan standard, and hope their marriage make them more active in 6lowpan WG. Congratulations, and let's have a social party at upcoming IETF if allowed. Looking forward to seeing all of you. Daniel -- Soohong Daniel Park http://www.soohongp.com --001485eaffd8332ed904864b4f4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks, long time no see in IETF.

I'd forward a good news to 6low= panner. Our colleagues in 6lowpan WG got merried.
Eunah and Dominik. http://hom= e.simula.no/~kaspar/wedding/ch/index.php

They are also good contributors to 6lowpan standard, and hope their mar= riage make them more active in 6lowpan WG.

Congratulations, and let&= #39;s have a social party at upcoming IETF if allowed.

Looking forwa= rd to seeing all of you.

Daniel
--
Soohong Daniel Park
http://www.soohongp.com
--001485eaffd8332ed904864b4f4e-- From tena@huawei.com Mon May 10 23:14:28 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0243F3A6898 for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 23:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.793 X-Spam-Level: X-Spam-Status: No, score=-99.793 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-RXizJf0Uoj for <6lowpan@core3.amsl.com>; Mon, 10 May 2010 23:14:25 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4C0A53A69C8 for <6lowpan@ietf.org>; Mon, 10 May 2010 23:14:13 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2800BQMRZDSC@szxga04-in.huawei.com> for 6lowpan@ietf.org; Tue, 11 May 2010 14:14:01 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2800JUURZDHR@szxga04-in.huawei.com> for 6lowpan@ietf.org; Tue, 11 May 2010 14:14:01 +0800 (CST) Received: from z00147053k ([10.70.39.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2800LHORZ8EX@szxml04-in.huawei.com> for 6lowpan@ietf.org; Tue, 11 May 2010 14:14:01 +0800 (CST) Date: Tue, 11 May 2010 14:13:56 +0800 From: Tina TSOU To: Daniel Park , 6lowpan@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: multipart/alternative; boundary="Boundary_(ID_sovJH5bSbNjJdK+R6W9hFA)" X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [6lowpan] non-technical, but good news to 6lowpanner X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 11 May 2010 06:14:28 -0000 This is a multi-part message in MIME format. --Boundary_(ID_sovJH5bSbNjJdK+R6W9hFA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Wow! Congratulations! Wish Eunah and Dominik could produce a little "6lowpanner" in the near future;-) B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message ----- From: Daniel Park To: 6lowpan@ietf.org Sent: Tuesday, May 11, 2010 2:05 PM Subject: [6lowpan] non-technical, but good news to 6lowpanner Folks, long time no see in IETF. I'd forward a good news to 6lowpanner. Our colleagues in 6lowpan WG got merried. Eunah and Dominik. http://home.simula.no/~kaspar/wedding/ch/index.php They are also good contributors to 6lowpan standard, and hope their marriage make them more active in 6lowpan WG. Congratulations, and let's have a social party at upcoming IETF if allowed. Looking forward to seeing all of you. Daniel -- Soohong Daniel Park http://www.soohongp.com ------------------------------------------------------------------------------ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --Boundary_(ID_sovJH5bSbNjJdK+R6W9hFA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Wow! Congratulations!
Wish Eunah and Dominik could produce a little "6lowpanner" in the near future;-)
 
----- Original Message -----
Sent: Tuesday, May 11, 2010 2:05 PM
Subject: [6lowpan] non-technical, but good news to 6lowpanner

Folks, long time no see in IETF.

I'd forward a good news to 6lowpanner. Our colleagues in 6lowpan WG got merried.
Eunah and Dominik.
http://home.simula.no/~kaspar/wedding/ch/index.php

They are also good contributors to 6lowpan standard, and hope their marriage make them more active in 6lowpan WG.

Congratulations, and let's have a social party at upcoming IETF if allowed.

Looking forward to seeing all of you.

Daniel
--
Soohong Daniel Park
http://www.soohongp.com

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
--Boundary_(ID_sovJH5bSbNjJdK+R6W9hFA)-- From erik.nordmark@oracle.com Tue May 11 02:07:15 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C8E28C11E; Tue, 11 May 2010 02:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.595 X-Spam-Level: X-Spam-Status: No, score=-3.595 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OpHTizc3Xhu; Tue, 11 May 2010 02:07:14 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id AFEA328C132; Tue, 11 May 2010 02:06:16 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4B95wgv019081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 May 2010 09:06:00 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4B268xm010068; Tue, 11 May 2010 09:05:56 GMT Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 254111531273568704; Tue, 11 May 2010 02:05:04 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 02:05:04 -0700 Message-ID: <4BE91DBA.9050803@oracle.com> Date: Tue, 11 May 2010 02:04:58 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7069.1272031181@marajade.sandelman.ca><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> <48B43071-DC1D-4CCD-80C5-161! CFC1C787C @sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60CB1@XMB-AMS-107.cisco.com> <4BE7F1DC.1! 060206@or acle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60D88@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01D60D88@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090205.4BE91DFA.01C6:SCFMA4539811,ss=1,fgs=0 Cc: roll@ietf.org, 6lowpan@ietf.org, zach.shelby@sensinode.com Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 11 May 2010 09:07:15 -0000 On 05/10/10 05:41 AM, Pascal Thubert (pthubert) wrote: > Hi Erik: > > I think Zach and I came up with a common understanding. My concern had > not to do with a backbone. It has to do with 2 routers in a same mesh > under topology, and without the assumption that any node can reach any > other node using the mesh under technology. > > To illustrate this, say you use the ND base draft in a Frame Relay > network. You build a hub and spoke with the router at the hub. The > router is at a central office, and there are DTEs at the branch office. > I agree, the draft works great! The router can resolve any incoming > packet because it has a proactive registration for it. Then we want to > place a second router. OK > We place a switch between those and we split the > DLCIs in half between the routers. So each of the routers get half of > the registrations. There is simply no DLCI for the hosts to register to > the other router. But that isn't how nd-09 works. See section 5.5. (The hosts register with more than one default router.) > In a same fashion, you do not want a node to register to all routers and > receive multicast from all routers in a LoWPAN that grows to the > thousands. If applications want to do multicast in a lowpan then the hosts would use MLD. That is orthogonal to the nd-09 registration option. > So with the draft alone, if router 1 gets a packet for a node attached > to router B, the registration does not help. So the router will either > multicast, which we wanted to avoid, or drop. That's my concern, that's > why I've been telling you it was broken for mesh under. Zach and I > agreed we could resolve this question by saying that 2 routers is > already an extended LoWPAN, that will be addressed by the spec left to > be done. Would you agree with that resolution? Might make sense for you to read nd-09, since it doesn't work that way. Erik From samitac@ipinfusion.com Tue May 11 17:02:49 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00E83A6A4C for <6lowpan@core3.amsl.com>; Tue, 11 May 2010 17:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfsQv71qRbpa for <6lowpan@core3.amsl.com>; Tue, 11 May 2010 17:02:49 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id D78753A69FC for <6lowpan@ietf.org>; Tue, 11 May 2010 17:02:48 -0700 (PDT) Received: (qmail 44521 invoked from network); 12 May 2010 00:02:36 -0000 Received: from (samitac@65.223.109.250 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 11 May 2010 17:02:36 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: qvNiXfIVM1lb63AZp2lpLwJEj70Qbgj40o2u82Zy4GFFb3Mbd_6uiA9Tg2b2dKId9ysmOBlMyAcoLptjKo89lTf2wiVWaMXw7xzbkRb.6xY7gAWdNfAVSF7eMP0hP1Fp8qanXJPsN58u_b6hERiC1WzVj_4cbbzyRfLSCmt_dreZVlz60DOcR5n9mTetPHgaSx6u9IeCrU5IKwiCi_TLq8WUKsv9iaifPN66zLtu5kpF88Jzrj71_mjZnu8p90RP X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Carsten Bormann'" , "'Zach Shelby'" References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> <48B43071-DC1D-4CCD-80C5-161C FC1C787C@sensinode.co m> <6AA3A1B1-8BC5-4C8D-BFEA-1B239C7E8923@tzi.org> In-Reply-To: <6AA3A1B1-8BC5-4C8D-BFEA-1B239C7E8923@tzi.org> Date: Tue, 11 May 2010 17:02:33 -0700 Message-ID: <007a01caf166$6c70cb10$45526130$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrwKi+EVXlIw6DSR/qxC5NAp1aVegBOU0uw Content-Language: en-us Cc: roll@ietf.org, zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 12 May 2010 00:02:49 -0000 Agree 100% on the following message below. Architecturally, it is clean, portable, compatible with multiple routing protocols if configuration and bootstrapping mechanisms such as addressing, context transfer etc. are separated from the functions of a routing protocol. RPL may be the only protocol being discussed currently at IETF, but as mentioned previously by others that there are other ad-hoc or IGP routing protocols that can be tweaked to run on a low-power and lossy networks for different configurations and applications. So, I completely disagree that RPL routing protocol carry the bootstrapping information. Also, for easy deployment and initial adoption of the technology, RPL would be better off if does not make itself complicated by trying to address all the possible permutation and combination of situations in LLN. Thanks, -Samita > > On May 10, 2010, at 11:55, Zach Shelby wrote: > > > We have already agreed that nothing in nd-09 prevents RPL from > disseminating the PIOs. In fact, it specifically says that if the routing > protocol does that already, then great. Other routing protocol might need > the prefix dissemination option in nd-09, thus the spec "stands on its own > feet". So as far as the 6lowpan WG is concerned there is nothing to discuss. > It is up to the ROLL working group to discuss if and how it wants to > disseminate prefix information to RPL routers. > > +1. > > However, please note also that a LoWPAN needs more information disseminated > than the PIOs. > Unless RPL is extended to carry compression context as well, it seems more > logical to do all this network configuration dissemination in 6LoWPAN-ND. > (No, you don't *need* compression context in a LoWPAN, but it gets > significantly less efficient without it. > And it breaks spectacularly if the compression context gets inconsistent > between nodes.) > > Both compression context and prefix information is likely to change on > relatively slow timescales (days/weeks), which is another reason why it > seems appropriate to use a configuration protocol for the dissemination of > both, rather than a routing protocol operating in terms of seconds/minutes. > > Gruesse, Carsten > From samitac@ipinfusion.com Tue May 11 17:52:08 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9433A6C3C for <6lowpan@core3.amsl.com>; Tue, 11 May 2010 17:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.087 X-Spam-Level: X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg5LUUGogbTA for <6lowpan@core3.amsl.com>; Tue, 11 May 2010 17:52:07 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id AD8103A6C3A for <6lowpan@ietf.org>; Tue, 11 May 2010 17:52:00 -0700 (PDT) Received: (qmail 93204 invoked from network); 12 May 2010 00:51:48 -0000 Received: from (samitac@65.223.109.250 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 11 May 2010 17:51:47 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: cKqPrHUVM1l1xKCDVXT0dsNRdkw3qTuhMG82lqaYevMN7ju6ZhHxO.GntCe.1uny4vxDLPg25w0b7dx.HlUwAju6as8VHxvhFv2TNRbVDgYjKWl1FhBxOOluKBh4t_XeQu.Y4beqGe3b4GJpzTw76GWU0mvp0H.O_gKnQUEzfJMce..PpMt3.3y8QTfUYlW2LaP1MhesTebZ5lDzANi5fKEGSYbR4EOTu.6X5kev1Y2KkxWzdrjDFF6KwGntD6ImaTJ2C0zfVkc7LfQs1XTPCZqcI7es7F_j X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: , "'Pascal Thubert \(pthubert\)'" , "'Erik Nordmark'" , References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com> <005a01caf046$8366a680$8a33f3 80$@sturek@att.net> In-Reply-To: <005a01caf046$8366a680$8a33f380$@sturek@att.net> Date: Tue, 11 May 2010 17:51:44 -0700 Message-ID: <007e01caf16d$4b39aa00$e1acfe00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrwDjw2JQxyX+I4SZuQhkCh63xQygAC/SmQAAsKcWAASFxu8A== Content-Language: en-us Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 12 May 2010 00:52:08 -0000 Hi Pascal, > > The expectation of the 6LoWPAN WG when we elected the backbone router draft > over Samita's draft was to radically eliminate multicast. The backbone [SC>] For the fact check and remembering the 6lowpan-ipv6-nd evolution: draft-chakrabarti-6lowpan-ipv6-nd-00 was published in Feb, 2006 co-authored by Erik and I. This draft introduced the concept optimization of IPv6 multicast signaling into unicast ones for IEEE 802.15.4 in mesh-under configuration. At Dublin, 2008, authors/chairs decided to merge v05 of this draft, draft-hui-6lowpan-nd, draft-thubert-backbone-router,draft-nordmark-6lowpan-reg-00 to add route-over and registration mechanism and produced draft-shelby-6lowpan-nd-* which was then adopted as wg draft. So no draft was particularly chosen over another draft. IMHO, that was the beginning of all-purpose (aka. Kitchen sink) 6lowpan-ND protocol which has had trouble in the wg as folks needed to implement unnecessary code for corner cases and unwanted usage. 6lowpan working group decided to split nd-07 to have a base draft. Nd-simple in Anaheim was an attempt to fix that problem. Wg welcomed the draft and ND-09 was created on the base idea of ND-simple and part of ND-08. ND-09 is not broken as claimed below. ND-09 is developed to address basic auto-configuration, minimal multicast and neighbor discovery with reliability while staying as close to RFC 4861 as possible for minimal code change. The white-boarding , backbone and extended lowpans etc. are not part of basic necessity in most applications in 6LoWPAN. The best way to handle them is to write a separate draft on them and move forward. Regards, -Samita > router draft takes a number of measures to get there. The most obvious is > the use of NS/NA as a registration mechanism, and I'm very happy that this > core idea is still present in the current draft, though the original author > somewhat disappeared by some black magic that's quite unusual to the IETF. > > I claim that the current proposed solution still does not work on mesh under > because it does not fulfill that expectation. For instance, I do not see how > multicast is avoided in mesh under when there are more than one router in > the subnet, without involving routing protocols, which would be route-over. > From the backbone router draft till ND-07, we answered that question at the > ND level using a whiteboard registrar as a backend to the registration. > Please do not confuse that question with the use of a backbone where > admittedly, either an SGP or ND proxy could work. > > I'll add that it is pretty hard to complete the registration mechanism > before we know what the registration bask end is. You demonstrated that > ND-08 could not be used to front end DHCP. I demonstrated that it cannot be > used to front end RPL either. And it's broken for mesh under because it is > incomplete. I cannot see how the whole picture works from either this draft > alone, or any combination of drafts on the works today. > > For all I know ND 09 is broken while ND 07 was not. My suggestion to resolve > the issues I see: > > - put the whiteboard interaction back in the base spec so the spec is > standing on its own 2 feet. > - let the route over problem propagation to RPL (that's the PIO/RIO > propagation) > - make a separate spec for the ND proxy piece. We have already text from > Zach, Carsten and I that can be used > > Cheers, > > Pascal > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abr@sdesigns.dk Wed May 12 01:16:40 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E56B3A6B0E; Wed, 12 May 2010 01:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.679 X-Spam-Level: X-Spam-Status: No, score=-0.679 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khlH2BK-5LcS; Wed, 12 May 2010 01:16:39 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 8AB253A69DC; Wed, 12 May 2010 01:16:38 -0700 (PDT) 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: Wed, 12 May 2010 10:16:27 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A144@zensys17.zensys.local> In-Reply-To: <007e01caf16d$4b39aa00$e1acfe00$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: AcrwDjw2JQxyX+I4SZuQhkCh63xQygAC/SmQAAsKcWAASFxu8AAQ3j+Q References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com><005a01caf046$8366a680$8a33f3 80$@stur ek@att.net> <007e01caf16d$4b39aa00$e1acfe00$@com> From: "Anders Brandt" To: "Samita Chakrabarti" , "Pascal Thubert (pthubert)" Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 12 May 2010 08:16:40 -0000 > The white-boarding , backbone and extended lowpans etc. are=20 > not part of basic necessity in most applications in 6LoWPAN.=20 > The best way to handle them is to write a separate draft on=20 > them and move forward. +1=20 > -----Original Message----- > From: 6lowpan-bounces@ietf.org=20 > [mailto:6lowpan-bounces@ietf.org] On Behalf Of Samita Chakrabarti > Sent: Wednesday, May 12, 2010 02:52 > To: d.sturek@att.net; 'Pascal Thubert (pthubert)'; 'Erik=20 > Nordmark'; zach.shelby@sensinode.com > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: Re: [6lowpan] [Roll] how does a node get an IP address >=20 > Hi Pascal, >=20 > >=20 > > The expectation of the 6LoWPAN WG when we elected the=20 > backbone router > draft > > over Samita's draft was to radically eliminate multicast.=20 > The backbone > [SC>] > For the fact check and remembering the 6lowpan-ipv6-nd evolution: >=20 > draft-chakrabarti-6lowpan-ipv6-nd-00 was published in Feb,=20 > 2006 co-authored by Erik and I. This draft introduced the=20 > concept optimization of IPv6 multicast signaling into unicast=20 > ones for IEEE 802.15.4 in mesh-under configuration. > At Dublin, 2008, authors/chairs decided to merge v05 of this=20 > draft, draft-hui-6lowpan-nd,=20 > draft-thubert-backbone-router,draft-nordmark-6lowpan-reg-00=20 > to add route-over and registration mechanism and produced > draft-shelby-6lowpan-nd-* which was then adopted as wg draft. >=20 > So no draft was particularly chosen over another draft. IMHO,=20 > that was the beginning of all-purpose (aka. Kitchen sink)=20 > 6lowpan-ND protocol which has had trouble in the wg as folks=20 > needed to implement unnecessary code for corner cases and=20 > unwanted usage. 6lowpan working group decided to split nd-07=20 > to have a base draft. >=20 > Nd-simple in Anaheim was an attempt to fix that problem. Wg=20 > welcomed the draft and ND-09 was created on the base idea of=20 > ND-simple and part of ND-08. >=20 >=20 > ND-09 is not broken as claimed below. ND-09 is developed to=20 > address basic auto-configuration, minimal multicast and=20 > neighbor discovery with reliability while staying as close to=20 > RFC 4861 as possible for minimal code change. > The white-boarding , backbone and extended lowpans etc. are=20 > not part of basic necessity in most applications in 6LoWPAN.=20 > The best way to handle them is to write a separate draft on=20 > them and move forward. >=20 > Regards, > -Samita >=20 > > router draft takes a number of measures to get there. The=20 > most obvious=20 > > is the use of NS/NA as a registration mechanism, and I'm very happy=20 > > that this core idea is still present in the current draft,=20 > though the=20 > > original > author > > somewhat disappeared by some black magic that's quite=20 > unusual to the IETF. > >=20 > > I claim that the current proposed solution still does not=20 > work on mesh > under > > because it does not fulfill that expectation. For instance,=20 > I do not=20 > > see > how > > multicast is avoided in mesh under when there are more than=20 > one router=20 > > in the subnet, without involving routing protocols, which would be > route-over. > > From the backbone router draft till ND-07, we answered that=20 > question=20 > > at > the > > ND level using a whiteboard registrar as a backend to the=20 > registration. > > Please do not confuse that question with the use of a=20 > backbone where=20 > > admittedly, either an SGP or ND proxy could work. > >=20 > > I'll add that it is pretty hard to complete the=20 > registration mechanism=20 > > before we know what the registration bask end is. You demonstrated=20 > > that > > ND-08 could not be used to front end DHCP. I demonstrated that it=20 > > cannot > be > > used to front end RPL either. And it's broken for mesh=20 > under because=20 > > it is incomplete. I cannot see how the whole picture works=20 > from either=20 > > this > draft > > alone, or any combination of drafts on the works today. > >=20 > > For all I know ND 09 is broken while ND 07 was not. My suggestion to > resolve > > the issues I see: > >=20 > > - put the whiteboard interaction back in the base spec so=20 > the spec is=20 > > standing on its own 2 feet. > > - let the route over problem propagation to RPL (that's the PIO/RIO > > propagation) > > - make a separate spec for the ND proxy piece. We have already text=20 > > from Zach, Carsten and I that can be used > >=20 > > Cheers, > >=20 > > Pascal > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > >=20 > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 From pthubert@cisco.com Wed May 12 04:31:44 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF6E3A6903; Wed, 12 May 2010 04:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.877 X-Spam-Level: X-Spam-Status: No, score=-4.877 tagged_above=-999 required=5 tests=[AWL=-2.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2fRCin8o0aF; Wed, 12 May 2010 04:31:42 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3E7163A67F4; Wed, 12 May 2010 04:31:41 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4BAFMu6kuQ/uCWiWdsb2JhbACeJxUBAQEKCxERBhyfepltgmaCLAQ X-IronPort-AV: E=Sophos;i="4.53,214,1272844800"; d="scan'208";a="7212466" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 12 May 2010 10:53:31 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4CBVTiO017502; Wed, 12 May 2010 11:31:29 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 13:31:29 +0200 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: Wed, 12 May 2010 13:31:23 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01DF4948@XMB-AMS-107.cisco.com> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A144@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: AcrwDjw2JQxyX+I4SZuQhkCh63xQygAC/SmQAAsKcWAASFxu8AAQ3j+QAAWZZeA= References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com><005a01caf046$8366a680$8a33f3 80$@stur ek@att.net> <007e01caf16d$4b39aa00$e1acfe00$@com> <6D9687E95918C04A8B30A7D6DA805A3E0142A144@zensys17.zensys.local> From: "Pascal Thubert (pthubert)" To: "Anders Brandt" , "Samita Chakrabarti" X-OriginalArrivalTime: 12 May 2010 11:31:29.0523 (UTC) FILETIME=[AA3A0C30:01CAF1C6] Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 12 May 2010 11:31:44 -0000 Hi Anders; The current ND draft has a white board, though it calls it a neighbor cache. Sometimes, renaming things is good. In this instance, I do not know. Clearly, standard neighbor cache entries must not be confused with the ones gleaned for the registration process, because only the latter can be fed into the backbone mechanism, be it route over or mesh under.=20 The White Board conceptually differs from the traditional Neighbor Cache: - The WB is a table as opposed to a cache. A neighbor cache entry can stay STALE for a very long time after the node is gone. A neighbor cache entry can be flushed to make room anytime. So a neighbor cache entry does not represent the node accurately enough to be redistributed in a routing protocol or proxied over a backbone.=20 - It is fed proactively using a registration as opposed to reactively to traffic. The registration and timely reregistration guarantees the presence of the node proactively. NUD is reactive, depends on traffic. It is nice to have but not mandatory as long as you have a registration. In a very constrained node, I'm not sure you really want to implement the additional 10 pages of specs that this represents. You should tell us. The original backbone router draft has the exact same white board as the current ND-09, and uses ND proxy over a backbone to allow for multiple routers in the subnet. For more complex topologies that include route over and complex meshes with no backbone, the WG doc evolved the concept to add a centralized registrar for the purpose of DAD and such. I got the message loud and clear that the group does not want that latter piece in the base spec: - which works if the spec is specific in which topologies it supports and which topologies it does not. That was clear in ND 08 section 2.2 but is gone from 09.=20 - which is good to speed up adoption of the registration, which is a great progress for ND at large . Cheers, Pascal > -----Original Message----- > From: Anders Brandt [mailto:abr@sdesigns.dk] > Sent: Wednesday, May 12, 2010 10:16 AM > To: Samita Chakrabarti; Pascal Thubert (pthubert) > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: RE: [6lowpan] [Roll] how does a node get an IP address >=20 >=20 > > The white-boarding , backbone and extended lowpans etc. are not part > > of basic necessity in most applications in 6LoWPAN. > > The best way to handle them is to write a separate draft on them and > > move forward. >=20 > +1 >=20 > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org > > [mailto:6lowpan-bounces@ietf.org] On Behalf Of Samita Chakrabarti > > Sent: Wednesday, May 12, 2010 02:52 > > To: d.sturek@att.net; 'Pascal Thubert (pthubert)'; 'Erik Nordmark'; > > zach.shelby@sensinode.com > > Cc: roll@ietf.org; 6lowpan@ietf.org > > Subject: Re: [6lowpan] [Roll] how does a node get an IP address > > > > Hi Pascal, > > > > > > > > The expectation of the 6LoWPAN WG when we elected the > > backbone router > > draft > > > over Samita's draft was to radically eliminate multicast. > > The backbone > > [SC>] > > For the fact check and remembering the 6lowpan-ipv6-nd evolution: > > > > draft-chakrabarti-6lowpan-ipv6-nd-00 was published in Feb, > > 2006 co-authored by Erik and I. This draft introduced the concept > > optimization of IPv6 multicast signaling into unicast ones for IEEE > > 802.15.4 in mesh-under configuration. > > At Dublin, 2008, authors/chairs decided to merge v05 of this draft, > > draft-hui-6lowpan-nd, > > draft-thubert-backbone-router,draft-nordmark-6lowpan-reg-00 > > to add route-over and registration mechanism and produced > > draft-shelby-6lowpan-nd-* which was then adopted as wg draft. > > > > So no draft was particularly chosen over another draft. IMHO, that was > > the beginning of all-purpose (aka. Kitchen sink) 6lowpan-ND protocol > > which has had trouble in the wg as folks needed to implement > > unnecessary code for corner cases and unwanted usage. 6lowpan working > > group decided to split nd-07 to have a base draft. > > > > Nd-simple in Anaheim was an attempt to fix that problem. Wg welcomed > > the draft and ND-09 was created on the base idea of ND-simple and part > > of ND-08. > > > > > > ND-09 is not broken as claimed below. ND-09 is developed to address > > basic auto-configuration, minimal multicast and neighbor discovery > > with reliability while staying as close to RFC 4861 as possible for > > minimal code change. > > The white-boarding , backbone and extended lowpans etc. are not part > > of basic necessity in most applications in 6LoWPAN. > > The best way to handle them is to write a separate draft on them and > > move forward. > > > > Regards, > > -Samita > > > > > router draft takes a number of measures to get there. The > > most obvious > > > is the use of NS/NA as a registration mechanism, and I'm very happy > > > that this core idea is still present in the current draft, > > though the > > > original > > author > > > somewhat disappeared by some black magic that's quite > > unusual to the IETF. > > > > > > I claim that the current proposed solution still does not > > work on mesh > > under > > > because it does not fulfill that expectation. For instance, > > I do not > > > see > > how > > > multicast is avoided in mesh under when there are more than > > one router > > > in the subnet, without involving routing protocols, which would be > > route-over. > > > From the backbone router draft till ND-07, we answered that > > question > > > at > > the > > > ND level using a whiteboard registrar as a backend to the > > registration. > > > Please do not confuse that question with the use of a > > backbone where > > > admittedly, either an SGP or ND proxy could work. > > > > > > I'll add that it is pretty hard to complete the > > registration mechanism > > > before we know what the registration bask end is. You demonstrated > > > that > > > ND-08 could not be used to front end DHCP. I demonstrated that it > > > cannot > > be > > > used to front end RPL either. And it's broken for mesh > > under because > > > it is incomplete. I cannot see how the whole picture works > > from either > > > this > > draft > > > alone, or any combination of drafts on the works today. > > > > > > For all I know ND 09 is broken while ND 07 was not. My suggestion to > > resolve > > > the issues I see: > > > > > > - put the whiteboard interaction back in the base spec so > > the spec is > > > standing on its own 2 feet. > > > - let the route over problem propagation to RPL (that's the PIO/RIO > > > propagation) > > > - make a separate spec for the ND proxy piece. We have already text > > > from Zach, Carsten and I that can be used > > > > > > Cheers, > > > > > > Pascal > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll > > > > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > From zach@sensinode.com Wed May 12 04:50:32 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5CF3A6B4D for <6lowpan@core3.amsl.com>; Wed, 12 May 2010 04:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gUOZqy7Au9Q for <6lowpan@core3.amsl.com>; Wed, 12 May 2010 04:50:30 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 9934F3A6B49 for <6lowpan@ietf.org>; Wed, 12 May 2010 04:50:29 -0700 (PDT) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4CBoCu2005734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 May 2010 14:50:12 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01DF4948@XMB-AMS-107.cisco.com> Date: Wed, 12 May 2010 14:50:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com><005a01caf046$8366a680$8a33f3! 80$@stur ek@att.net> <007e01caf16d$4b39aa00$e1acfe00$@com> <6D9687E95918C04A8B30A7D6DA805A3E0142A144@zensys17.zensys.local> <6A2A459175DABE4BB11DE2026AA50A5D01DF4948@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1077) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 12 May 2010 11:50:32 -0000 Hi Pascal, Great to see we are converging here. So I think the best next actions = would be the following: 1. Write an I-D examining the different topologies for connecting = LoWPANs to other networks, and the issues/solutions for dealing with = that. I think it would be useful to explore both how it works when a = routing protocol is run over the backbone, as well as proxy ND. This = should reference and use nd-09 as-is so we see if anything is broken or = needs better explaining.=20 2. We should do a better job of defining the assumptions for the = topologies this works for (and doesn't), in particular the optional DAD = to the 6LBR. We have a pretty clear picture in our heads, but it could = be more concrete the draft. I propose making a ticket for that and = fixing it for nd-10.=20 Now, it would be great to go back to reviewing nd-09 for technical = correctness and nits, which would be a big help. So far I have one = ticket from Pascal plus comments from Robert Cragie, so I guess everyone = else is happy?=20 Thanks, Zach On May 12, 2010, at 14:31 , Pascal Thubert (pthubert) wrote: > I got the message loud and clear that the group does not want that > latter piece in the base spec: > - which works if the spec is specific in which topologies it supports > and which topologies it does not. That was clear in ND 08 section 2.2 > but is gone from 09.=20 > - which is good to speed up adoption of the registration, which is a > great progress for ND at large . --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From pthubert@cisco.com Wed May 12 05:28:22 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA71128C147 for <6lowpan@core3.amsl.com>; Wed, 12 May 2010 05:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.836 X-Spam-Level: X-Spam-Status: No, score=-8.836 tagged_above=-999 required=5 tests=[AWL=1.763, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUFXBVUeinz0 for <6lowpan@core3.amsl.com>; Wed, 12 May 2010 05:28:21 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F098F3A6CA2 for <6lowpan@ietf.org>; Wed, 12 May 2010 05:23:45 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4BAMM66kuQ/uCWiWdsb2JhbACeJxUBAQEKCxERBhygI5lshRIE X-IronPort-AV: E=Sophos;i="4.53,215,1272844800"; d="scan'208";a="61153593" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 May 2010 12:23:34 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4CCNYJQ001447; Wed, 12 May 2010 12:23:34 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 14:23:34 +0200 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: Wed, 12 May 2010 14:23:29 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01DF4990@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: AcrxyVtLWVUBbOmCQyKYZ07HQLqc8gAAFiUw References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com><005a01caf046$8366a680$8a33f3! 80$@st ur ek@att.ne t> <007e01caf16d$4b39aa00$e1acfe00$@com> <6D9687E95918C04A8B30A7D6DA805A3E0142A144@zensys17.zensys.local> <6A2A459175DABE4BB11DE2026AA50A5D01DF4948@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" X-OriginalArrivalTime: 12 May 2010 12:23:34.0559 (UTC) FILETIME=[F0E4B2F0:01CAF1CD] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 12 May 2010 12:28:22 -0000 Good Afternoon, Zach: I still think that splitting the registration mechanism and the diffusion mechanism in 2 drafts would help speed up the registration piece. Which is a corner stone for the whole work, not only at 6LoWPAN. I have a number of other issues on the registration piece. To start with: - the sequence number that was present in http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-01#sect ion-4.1 is gone from the http://tools.ietf.org/html/draft-ietf-6lowpan-nd-09#section-4.1 . MIPv6 showed us that this sequence is a useful tool for resynchronization and to defeat replay attacks. The sequence number will also play a role in the movement resolution over the backbone. I suggest you place it back. - http://tools.ietf.org/html/draft-ietf-6lowpan-nd-09#section-8.2 discusses the use of the white board for DAD in more complex topologies. But the group does not seem to want to see it in this spec. So is it in or out of scope? If in scope (which I definitely support), then there's no point restricting it to route over. A mesh under without a backbone must have one LBR and a number of LR that will do the exact same operation as described in that section. And I'll be happy that the spec stands on its own 2 feet. We'll not that a backbone is by definition a link between LBRs, and out of scope. Would you agree? Thanks for all the sweat! Pascal > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com] > Sent: Wednesday, May 12, 2010 1:50 PM > To: Pascal Thubert (pthubert) > Cc: 6lowpan > Subject: Re: [6lowpan] [Roll] how does a node get an IP address >=20 > Hi Pascal, >=20 > Great to see we are converging here. So I think the best next actions would > be the following: >=20 > 1. Write an I-D examining the different topologies for connecting LoWPANs > to other networks, and the issues/solutions for dealing with that. I think it > would be useful to explore both how it works when a routing protocol is run > over the backbone, as well as proxy ND. This should reference and use nd-09 > as-is so we see if anything is broken or needs better explaining. >=20 > 2. We should do a better job of defining the assumptions for the topologies > this works for (and doesn't), in particular the optional DAD to the 6LBR. We > have a pretty clear picture in our heads, but it could be more concrete the > draft. I propose making a ticket for that and fixing it for nd-10. >=20 > Now, it would be great to go back to reviewing nd-09 for technical > correctness and nits, which would be a big help. So far I have one ticket from > Pascal plus comments from Robert Cragie, so I guess everyone else is happy? >=20 > Thanks, > Zach >=20 > On May 12, 2010, at 14:31 , Pascal Thubert (pthubert) wrote: >=20 > > I got the message loud and clear that the group does not want that > > latter piece in the base spec: > > - which works if the spec is specific in which topologies it supports > > and which topologies it does not. That was clear in ND 08 section 2.2 > > but is gone from 09. > > - which is good to speed up adoption of the registration, which is a > > great progress for ND at large . >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 From pal@cs.stanford.edu Wed May 12 14:59:56 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC393A694C; Wed, 12 May 2010 14:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.373 X-Spam-Level: X-Spam-Status: No, score=-5.373 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U48RBL1KKHU0; Wed, 12 May 2010 14:59:55 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 631733A68E3; Wed, 12 May 2010 14:59:55 -0700 (PDT) Received: from dnab404679.stanford.edu ([171.64.70.121]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OCJxu-0002IB-1l; Wed, 12 May 2010 14:59:44 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01D60A35@XMB-AMS-107.cisco.com> Date: Wed, 12 May 2010 14:59:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7EF9EC0D-E9AF-4BB1-A3D8-605C18D8BCD8@cs.stanford.edu> References: <6A2A459175DABE4BB11DE2026AA50A5D01D608E0@XMB-AMS-107.cisco.com>(pthubert@cisco.com) <87wrvfzrvo.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60A35@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1078) X-Scan-Signature: dcedbbeaec314583a5a6d4e37e27e533 Cc: roll@ietf.org, zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 12 May 2010 21:59:56 -0000 On May 9, 2010, at 9:41 AM, Pascal Thubert (pthubert) wrote: > Hi Richard >=20 >=20 >>> The flow label helps the router select the instance for a packet. >>=20 >> "Helps"? Doesn't the flow label tell the router exactly which > instance to use? >=20 > At the moment you're correct, it's one to one. I've heard voices (was > that Kris and Phil?) asking for a more complex stateful mapping at the > RPL network ingress, and a new field in the new RPL option for the > instance. My vote is to leave the instance ID in the flow label where = it > is today, since it is end to end application data. While I agree that > the loop avoidance data fits very well in a hop by hop option long as > the option stays contained in the RPL network. Which is what = Jonathan's > draft does for all I understand so I'm fully happy there. Pascal, I still don't understand how this could possibly work. I'm an = application on the Internet. I want to send packets to a RPL node. How = am I supposed to set the flow label? You are assuming an out-of-band = communication mechanism to set the label. This requires a sender to know = that the endpoint is a RPL node; does this really seem like a good idea? = Instance IDs MUST work when a sender does not know the destination runs = RPL. RPL therefore MUST solve the case where the sender does not set a = flow label. Otherwise only nodes that are aware of RPL and can determine = the instance ID can communicate with RPL nodes. This does not seem like = a good idea to me... The current proposed mechanism is that there is an optional RPL IPv6 = header that specifies the instance ID. If that header is not present, = then RPL can assume the instance ID is in the flow label. Phil From robert.cragie@gridmerge.com Fri May 14 08:26:45 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F923A6841 for <6lowpan@core3.amsl.com>; Fri, 14 May 2010 08:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVeqvWETv3Hm for <6lowpan@core3.amsl.com>; Fri, 14 May 2010 08:26:43 -0700 (PDT) Received: from hiltonsmtp.worldspice.net (hiltonsmtp.worldspice.net [216.37.94.58]) by core3.amsl.com (Postfix) with ESMTP id 88A293A67FB for <6lowpan@ietf.org>; Fri, 14 May 2010 08:26:41 -0700 (PDT) Received: (qmail 1610 invoked by uid 0); 14 May 2010 15:26:30 -0000 Received: by simscan 1.4.0 ppid: 1274, pid: 1471, t: 2.5792s scanners: clamav: 0.94.1/m:50/d:9101 spam: 3.2.5 Received: from unknown (HELO ?172.28.172.111?) (robert.cragie@gridmerge.com@209.117.68.2) by hiltoncluster01.worldspice.net with ESMTPA; 14 May 2010 15:26:27 -0000 Message-ID: <4BED6B9B.1060305@gridmerge.com> Date: Fri, 14 May 2010 16:26:19 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010409020203080500050201" Subject: [6lowpan] Comments on draft-ietf-6lowpan-nd-09 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 15:26:46 -0000 This is a cryptographically signed message in MIME format. --------------ms010409020203080500050201 Content-Type: multipart/alternative; boundary="------------010508000906070704060307" This is a multi-part message in MIME format. --------------010508000906070704060307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Here is a list of comments and typos on draft-ietf-6lowpan-nd-09. I=20 tried to send this as marked-up HTML (much easier to read) but it won't=20 let me, so here are the distilled comments. Robert Comments: page 5: "DAD of use multicast" - grammar? "from the same prefix can be used" - 'reached' instead of 'used'? page 7: "EUI-64s are globally unique" - What about the case of spoofed/cloned=20 EUI-64s? What would be the effect using this ND? Would it be=20 significant? My guess is probably not but it might be worth making this=20 clear page 8: "However, the Address Registration mechanism might be useful for other=20 link layer technologies" - I would have thought all the mechanisms and=20 modifications may apply to other link layer technologies page 9: The process during which a LoWPAN node sends an Neighbor Solicitation=20 message - Is "LoWPAN node" a specific term? If so, needs to be defined.=20 I would also suggest it is called 6LoWPAN Node (6LN?) to be consistent "that allows for sleeping nodes" - 6LoWPAN nodes? Check for this=20 throughout the document "initial set of default routers" - This might seem pedantic, but=20 "Router" (with an uppercase R) is defined in this document and "router"=20 (with a lowercase r) is defined in RFC4861 and they are subtly=20 different. Maybe have this consistency across the document page 10: "which in turn use normal Neighbor Discovery mechanisms to convey this=20 information to the hosts" - I think this is questionable; there are some = differences "DAD is optional if DHCPv6 is used to assign addresses" - Or an=20 alternative address assignment mechanism page 12: "In this case, the Neighbor Solicitation and Advertisement messages will = be forwarded between the 6LR and 6LBRs" - This is overloading the=20 original use of NS/NA as defined in RFC4861 quite a lot and changing the = rules. There seemed to be resistance to defining a new message but=20 wouldn't that actually be better? page 16: C: 1-bit context compression flag - I would add the proposed text at the = end of the definition to make it clear what this flag is for: "This flag = is used to manage the context lifecycle based on the recommendations in=20 Section 7.2" page 18: "and sent to the IPv6 All-Routers multicast address" - There is also a=20 case for being able to send unicast as it is possible the host has=20 discovered which router it wishes to join the network through by other=20 means, e.g. 802.15.4 beacon request. This could potentially limit=20 traffic. Section 5.8.2 also says it can be sent unicast. page 19: "This includes the Context ID, the prefix" - Possibly some confusion=20 between the context prefix and the prefix in the PIO. Maybe clarfication = on the terminology is needed. page 21: "or the appropriate IP-over-foo document" - Is this a well-known phrase=20 in the IETF community? :-) page 25: "then care should be taken to ensure that there isn't a flood of=20 ARO-carrying messages **sent** to the 6LBR as each router hears an ARO=20 from their neighboring routers" - Is this likely to happen with a=20 unicast to 6LBR? (** typo 'send' -> 'sent' **) page 28: "then the RA MUST be silently ignored" - "Silently ignored" is a=20 tautology. Either "silently discarded" or simply "ignored" page 29: "The routers periodically send Router Advertisements" - "may=20 periodically send"? It is optional, isn't it? Also might be worth=20 mentioning this information could be disseminated by other mechanisms. page 30: 8.2.1. Special Message Validation - This is a rather complex rule for=20 NS/NA processing as the hop limit processing may well happen before=20 payload processing. Could it be made simpler or more logical? page 31: "It proceeds to look for the Registration Address in the DAD Table. If=20 an entry is found and the recorded EUI-64 is different than the EUI-64=20 in the ARO, then it returns an NA with the ARO Status set to 1=20 ('Duplicate Address'). Otherwise it returns an NA with ARO Status set=20 to zero." - It would be really nice if it could also return a 'suggested = address'. This would complete address assignment without the host having = to guess again. page 33: Figure 3: Do you need the 'NS' and 'NA' component in the diagram? It=20 makes it inconsistent with Figure 2. Typos: The change is bracketed by page 7: Optimize Neighbor Discovery with mechanisms that=20 are minimal yet sufficient for the operation in both mesh-under=20 and route-over configurations. Provide support for sleeping hosts. Provide an optional duplicate address=20 detection mechanism suitable for route-over LoWPANs page 8: Note that nothing in this document precludes a node being a router on some interfaces page 9: In a mesh-under configuration only 6LBRs and = hosts exist; there are no 6LRs in mesh-under = topologies The most important part of the optimizations = is the evolved host-to-router interaction that allows for sleeping page 11: In an isolated LoWPAN, a ULA page 19: The host SHOULD unicast a Router Solicitation= Unicast Neighbor Solicitation (NS) messages are sent by hosts page 21: Link-layer addresses for neighbors are stored in Neighbor Cache entries=20 [RFC4861]. In order to achieve LoWPAN compression page 23: in the Router Advertisement messages it sends. =20 If the 6LR has received RAs from different=20 6LBRs, with the same or different prefixes and context information,=20 then it will page 24: Section 8.2 specifies optional behavior=20 for a 6LBR for other If the NS contains a valid ARO, then the router inspects its Neighbor=20 Cache on the arriving interface to see if it is a duplicate. If there is no Neighbor Cache entry for the IPv6 source=20 address of the NS or if there is such a Neighbor Cache entry and the=20 EUI-64 is the same, then it isn't a duplicate. Otherwise it is a=20 duplicate address. page 25: When routers use ARO to register with each other and the optional DAD to = the 6LBR is in use (= Section=20 8.2), then care should be taken to ensure that there isn't a=20 flood of ARO-carrying messages sent to the=20 6LBR as each router page 27: Optionally the Router Advertisement messages can be used to disseminate=20 prefixes and contexts to all page 28: then the routers follow [RFC4861], which states that= =20 they merely do some it sends the 'expiry time', preventing accidentally = moving further into the future. For example, if a 6CO with a=20 Valid lifetime of 10 minutes is received at=20 time T, and the router includes this in a RA it sends at time T+5 minutes= If multihop distribution is performed using RA messages, then the=20 routers MUST ensure that the ABRO always stays=20 together page 29: The routers also respond to Router=20 Solicitations by unicasting RA messages page 30: Neighbor Cache. This conceptual data structure is=20 called the DAD table. It is indexed by page 31: When a 6LBR that implements the optional multihop DAD receives an NS=20 from a 6LR, which contains an ARO with Length= =20 =3D 4, then it MUST NOT verify that the hop limit is 255 as specified=20 above. It proceeds to look for the=20 Registration Address in the DAD Table page 33: one might want to use Secure Neighbor=20 Discovery (SeND) --=20 Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com --------------010508000906070704060307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here is a list of comments and typos on draft-ietf-6lowpan-nd-09. I tried to send this as marked-up HTML (much easier to read) but it won't let me, so here are the distilled comments.

Robert

Comments:

page 5:

"DAD of use multicast" - grammar?
"from the same prefix can be used" - 'reached' instead of 'used'?

page 7:

"EUI-64s are globally unique" - What about the case of spoofed/cloned EUI-64s? What would be the effect using this ND? Would it be significant? My guess is probably not but it might be worth making this clear

page 8:

"However, the Address Registration mechanism might be useful for other link layer technologies" - I would have thought all the mechanisms and modifications may apply to other link layer technologies

page 9:

The process during which a LoWPAN node sends an Neighbor Solicitation message - Is "LoWPAN node" a specific term? If so, needs to be defined. I would also suggest it is called 6LoWPAN Node (6LN?) to be consistent
"that allows for sleeping nodes" - 6LoWPAN nodes? Check for this throughout the document

"initial set of default routers" - This might seem pedantic, but "Router" (with an uppercase R) is defined in this document and "router" (with a lowercase r) is defined in RFC4861 and they are subtly different. Maybe have this consistency across the document

page 10:

"which in turn use normal Neighbor Discovery mechanisms to convey this information to the hosts" - I think this is questionable; there are some differences

"DAD is optional if DHCPv6 is used to assign addresses" - Or an alternative address assignment mechanism

page 12:

"In this case, the Neighbor Solicitation and Advertisement messages will be forwarded between the 6LR and 6LBRs" - This is overloading the original use of NS/NA as defined in RFC4861 quite a lot and changing the rules. There seemed to be resistance to defining a new message but wouldn't that actually be better?

page 16:

C: 1-bit context compression flag - I would add the proposed text at the end of the definition to make it clear what this flag is for: "This flag is used to manage the context lifecycle based on the recommendations in Section 7.2"

page 18:

"and sent to the IPv6 All-Routers multicast address" - There is also a case for being able to send unicast as it is possible the host has discovered which router it wishes to join the network through by other means, e.g. 802.15.4 beacon request. This could potentially limit traffic. Section 5.8.2 also says it can be sent unicast.

page 19:

"This includes the Context ID, the prefix" - Possibly some confusion between the context prefix and the prefix in the PIO. Maybe clarfication on the terminology is needed.

page 21:

"or the appropriate IP-over-foo document" - Is this a well-known phrase in the IETF community? :-)

page 25:

"then care should be taken to ensure that there isn't a flood of ARO-carrying messages **sent** to the 6LBR as each router hears an ARO from their neighboring routers" - Is this likely to happen with a unicast to 6LBR? (** typo 'send' -> 'sent' **)

page 28:

"then the RA MUST be silently ignored" - "Silently ignored" is a tautology. Either "silently discarded" or simply "ignored"

page 29:

"The routers periodically send Router Advertisements" - "may periodically send"? It is optional, isn't it? Also might be worth mentioning this information could be disseminated by other mechanisms.
page 30:

8.2.1. Special Message Validation - This is a rather complex rule for NS/NA processing as the hop limit processing may well happen before payload processing. Could it be made simpler or more logical?

page 31:

"It proceeds to look for the Registration Address in the DAD Table. = If an entry is found and the recorded EUI-64 is different than the EUI-64 in the ARO, then it returns an NA with the ARO Status set to 1 ('Duplicate Address').  Otherwise it returns an NA with ARO Status s= et to zero." - It would be really nice if it could also return a 'suggested address'. This would complete address assignment without the host having to guess again.

page 33:

Figure 3: Do you need the 'NS' and 'NA' component in the diagram? It makes it inconsistent with Figure 2.

Typos:

The change is bracketed by <span class=3Dhilite></span>

page 7:

Optimize Neighbor Discovery with <span class=3Dhilite>mechanisms that are</span> minimal yet sufficient for the operation in both mesh-under and route-over configurations.

<span class=3Dhilite>Provide s</span>upport for sleeping hosts.

<span class=3Dhilite>Provide an o</span>ptional duplicate address detection mechanism suitable for route-over LoWPANs

page 8:
 
Note that nothing in this document precludes a node <span class=3Dhilite>being</span> a router on some interfaces

page 9:

In a mesh-under configuration only <span class=3Dhilite>6LBRs</span> and hosts exist; there are no <span class=3Dhilite>6LRs</span> in mesh-under topologies
=
The most important part of the <span class=3Dhilite>optimizations</span> is the evolved host-to-router interaction that allows for sleeping

page 11:

In an isolated <span class=3Dhilite>LoWPAN,</span> a ULA

page 19:

The host SHOULD unicast <span class=3Dhilite>a</span> Router Solicitation

Unicast Neighbor Solicitation (NS) messages are <span class=3Dhilite>sent</span> by hosts

page 21:

Link-layer addresses for neighbors are stored in Neighbor Cache entries [<A href=3D"http://tools.ietf.org/html/rfc4861" title=3D"&quot;Neighbor Discovery for IP version 6 (IPv6)&quot;">RFC4861</A><span class=3Dhilite>]. = </span>In order to achieve LoWPAN compression

page 23:

in the Router Advertisement messages it sends.<span class=3Dhilite>  If</span> the 6LR has <span class=3Dhilite>received RAs from different 6LBRs, with the same or different prefixes and context information, </span> then it will
page 24:

Section 8.2</A> <span class=3Dhilite>specifies</span> optional behavior for a 6LBR for other

If the NS contains a valid ARO, then the router inspects its Neighbor Cache on the arriving interface to see if it is a duplicate.  <sp= an class=3Dhilite>If there is no Neighbor Cache entry for the IPv6 source= address of the NS or if there is such a Neighbor Cache entry and the EUI-64 is the same, then it isn't a duplicate.  Otherwise it is a duplicate address.</span>

page 25:

When routers use ARO to register with each other and the optional DAD to the 6LBR <span class=3Dhilite>is in use (<A href=3D"http://tools.ietf.org/html/dra= ft-ietf-6lowpan-nd-09#section-8.2">Section 8.2</A>),</span> then care should be taken to ensure that there isn't a flood of ARO-carrying messages <span class=3Dhilite>sent</span> to the 6LBR as each router

page 27:

Optionally the Router Advertisement messages can be used to disseminate <span class=3Dhilite>prefixes and contexts</span> to all

page 28:

then the routers follow [<A href=3D"http://tools.ietf.org/html/rfc4861" title=3D"&quot;= Neighbor Discovery for IP version 6 (IPv6)&quot;">RFC4861</A>]<span class=3Dhilite>, which</span> states that they merely do some

it sends the 'expiry time'<span class=3Dhilite>, preventing accidentally moving</span> further into the future.  For examp= le, if a 6CO with a Valid lifetime of 10 minutes is <span class=3Dhilite>received</span> at time T, and the router includes this in a RA it sends at time T+5 minutes

If multihop distribution is performed using RA messages, then the routers MUST ensure that the ABRO always <span class=3Dhilite>stays</span> together

page 29:

<span class=3Dhilite>The routers</span> also respond to Router Solicitations by unicasting RA messages

page 30:

Neighbor Cache.  <span class=3Dhilite>This conceptual data structure is called the DAD table.</span>  It is indexed by
page 31:

When a 6LBR that implements the optional multihop DAD receives an NS from a 6LR, <span class=3Dhilite>which contains</span> an ARO= with Length =3D 4, then it MUST NOT verify that the hop limit is 255 as specified above.  <span class=3Dhilite>It</span> proceed= s to look for the Registration Address in the DAD Table

page 33:

one might want to use <span class=3Dhilite>Secure</span> Neighbor Discovery <span class=3Dhilite>(SeND)</span>

--

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

--------------010508000906070704060307-- --------------ms010409020203080500050201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MTQxNTI2MTlaMCMGCSqGSIb3DQEJBDEWBBTHrIBbTrySiF80OyzvLte2X9aN9TBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBACb4eo1ZpeOrnI8/ud7OjSbRK3bu9qPp8zbubU0vbOuZMuTAG1+aUZ0AMYF3T+1IKohk HQbHKg6HLm0jc631hPqOuoQAuKCnsqOuT2/DUWY/irup8yS7YmIaTNLloznEcjTx/ZJwPBBN +lpfkr+FGi+qloOuyhw/99/kzCSTr0GF5Xbs9zUinC3gdcer2mDr5DN9mgyzRy8VcK78bn3T fp/Ufq+aMESpiYL4kx0acuS1clb2nhqdfbMggseXxnkQTBObovzzW5BvzC26uX5Dh5impKY/ zJq5r6bMVouVImtvZDQqyyhtWA2InUL6oTHoytYnwBJHOkzzwmdtXXkUDLIAAAAAAAA= --------------ms010409020203080500050201-- From adam@sics.se Mon May 17 09:32:11 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1766C3A6A57; Mon, 17 May 2010 09:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_99=3.5, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX63ABrsvrgf; Mon, 17 May 2010 09:32:10 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 2A46C3A6A27; Mon, 17 May 2010 09:26:55 -0700 (PDT) Received: from [10.1.1.224] (unknown [10.1.1.224]) by letter.sics.se (Postfix) with ESMTPS id 02E654012A; Mon, 17 May 2010 18:26:45 +0200 (CEST) Message-ID: <4BF16D22.5080602@sics.se> Date: Mon, 17 May 2010 18:21:54 +0200 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: roll WG , 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowpan] CFP ACM BuildSys 2010, in conjunction with ACM SenSys 2010 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 17 May 2010 16:32:11 -0000 Call for papers: ACM BuildSys 2010, in conjunction with ACM SenSys 2010 http://buildsys.org/2010 2nd ACM Workshop On Embedded Sensing Systems For Energy-Efficiency In Buildings and Surroundings Zurich, Switzerland - November 2, 2010. Important dates: * Submission deadline: 30 July 2010 * Notification of acceptance: 7 September 2010 * Camera Ready Due: 25 September 2010 * Workshop date: 2 November 2010 Technically co-sponsored by ACM[1]. Submissions will be peer-reviewed. The Proceedings will be archived in the ACM Digital Library. The World is increasingly experiencing a strong need for energy consumption reduction and a need for efficient use of scarce natural resources. Official studies report that buildings account for the largest portion of World's energy expenditure and have the fastest growth rate. Clearly, energy saving strategies that target energy use in buildings and surroundings can have a major impact worldwide, driving the current energy market toward self-sufficiency and self-sustainability. This calls for effective techniques and methods that enable accurate carbon foot printing, monitoring and control of appliance activity, energy auditing and management in buildings and surroundings and the generation of energy awareness. Wireless sensor networks (WSNs) plays a key role in enabling energy-saving systems in buildings and surrounding spaces by providing a reliable, cost-effective and extensible solution that can be placed in existing as well as new structures and be controlled via the Internet. In fact, WSNs allow the monitoring of the energy consumption in near-real time and, as such, they are an essential tool in the control loop that will be used in future structures for the generation and usage of diverse types of energy. Following the success of the past edition of the workshop, BuildSys 2010 focuses on the intersection between WSNs and energy in buildings by merging experts in the WSN domain and experts in the Building/Energy community in order to identify innovative solutions which achieve the broad goal of energy-reduction. The workshop welcomes sensor network-based techniques and applications that can clearly demonstrate how to: * Increase energy awareness and reduce consumption by leveraging on sensing systems/social networking/mobile phones, novel visualization and other forms of media to convey relevant information to users; * Systems that can influence a change of building occupant behaviour towards a more parsimonious usage of electricity, gas, heating, water, etc.; * Monitor and actuate appliances in residential and industrial settings (e.g. data centres, HVAC, etc.) * Monitor and control of alternative energy sources aiming at an increase of production efficacy; * Model and simulate heating cooling lighting, ventilation, water usage and other energy flows in buildings and surrounding spaces through the combination of real data from sensors and popular energy simulation tools such as Energy Plus and TrnSys; * Create innovative tools to model and visualize energy expenditure and production (from, e.g., solar panels, wind turbines); * Integrate sensor-based systems to improve grid operation and energy distribution (electricity, gas, water); Particular emphasis will also be given to: * Real evaluation of energy-saving techniques and case studies that demonstrate a decrease of energy expenditure in real scenarios; * Design of innovative architectures that are capable of reducing energy consumption and improve energy use efficiency; * Accurate case studies and issues experienced current energy systems and how sensor networks can improve the state of the art in building energy management; * Sensor systems for the identification of appliances in industrial and home environments, which can be used to estimate the energy usage/production model and to predict future demands; * Innovative Sensor Network-assisted building monitoring systems (BMS); * Integration of WSNs and wired sensor systems (e.g., Powerline, exing BMS) for the energy management in buildings. General Chair * Antonio Ruzzelli, University College Dublin, Ireland Steering Committee * Adam Dunkels, SICS, Sweden * Antonio Ruzzelli, University College Dublin, Ireland * David Culler, University of Berkeley, US * Michele Rossi, Universita’ di Padova, Italy Publication Chair * Rasit Eskicioglu, University of Manitoba, Canada Local Arrangement Chair * Philipp Sommer, ETH, Switzerland TPC Chairs * Alberto Cerpa, UC Merced, US * Dirk Pesch, CIT, IE TPC * Adam Dunkels, (SICS, SE) * Anthony Schoofs, (UCD, IE) * Cormac Sreenan, (UCC, IE) * David Culler,(UC Berkeley, US) * Kamin Whitehouse, (Virginia University, US) * Mani Srivastava, (UCLA, US) * Prabal Dutta, (University of Michigan, US) * Roger Wattenhofer, (ETH, CH) * Tommaso Melodia, (SUNY Buffalo, US) * Alain Zarli, (CSTB, FR) * Dietrich Schmidt, (Fraunhofer institute, GE) * Francis Rubinstein, (LBNL, US) * Peter Fuhrmann, (Philips research, GE) * Guy Newsham (National Research Council, CA) * José J. de las Heras, (Acciona research, SP) * Marcus Keane, (NUI, IE) * Martijn Bennebroek, (Philips Research, NL) * Paul Bertrand, (Watteco Technologies) * Sandra Scalari, (ENEL research, IT) * Xiaofan Jiang, (UC Berkeley, US) [1] Approval from ACM is pending. -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From eunah.ietf@gmail.com Wed May 19 03:04:27 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4723A681F for <6lowpan@core3.amsl.com>; Wed, 19 May 2010 03:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFNe0yZvenTy for <6lowpan@core3.amsl.com>; Wed, 19 May 2010 03:04:25 -0700 (PDT) Received: from mail-qy0-f200.google.com (mail-qy0-f200.google.com [209.85.221.200]) by core3.amsl.com (Postfix) with ESMTP id 471DD3A690E for <6lowpan@ietf.org>; Wed, 19 May 2010 03:04:19 -0700 (PDT) Received: by qyk38 with SMTP id 38so8292484qyk.17 for <6lowpan@ietf.org>; Wed, 19 May 2010 03:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0OWdyr/UDTKw0uWD1af2kxh3wY3vrnRznrZeObMca4A=; b=efFafee+Ni3B7zvrhc7iiB7AIOTzFPHpxH5c1GppmQgY7tHBGl5FrnqHzMeXiOSGJP OB929HcRdn83t5q97yn4PEeoAob12vNCg0y6ICj2vCSxQXLp/4bbYKxZj6xTJkFQC8Jy 65PNGNDdYVnORxsEpreU7zOczwfHLB317QltA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=w5f3QiGa3cWXOwJzajNyq5xORsBct09gK42cvcEtsrgDuW44kh3AxTPFRYyBYpghy/ AGtTFQY5GHpcMWZUTl9WTU2hpALVCRcDpelyew1xQr6Xfoa8k2S0qUYolNmlSt3ev/ZL /vB7VuQJd7CB6Ax4QUxLdSdu3hAX52pHCK8TY= MIME-Version: 1.0 Received: by 10.229.231.202 with SMTP id jr10mr42906qcb.115.1274263448249; Wed, 19 May 2010 03:04:08 -0700 (PDT) Received: by 10.229.78.136 with HTTP; Wed, 19 May 2010 03:04:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 May 2010 19:04:08 +0900 Message-ID: From: "Eunsook \"Eunah\" Kim" To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] non-technical, but good news to 6lowpanner X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 19 May 2010 10:04:27 -0000 Wow, Daniel, I didn't expect this news flew to 6lowpanner list. :P Thanks for your big congratulations. Tina, Haha, let see. :) Thanks for your greetings as well. :) Thanks all, Eunah On Tue, May 11, 2010 at 3:13 PM, Tina TSOU wrote: > Wow! Congratulations! > Wish Eunah and Dominik could produce a little "6lowpanner" in the near > future;-) > > B. R. > Tina > http://tinatsou.weebly.com/contact.html > > ----- Original Message ----- > From: Daniel Park > To: 6lowpan@ietf.org > Sent: Tuesday, May 11, 2010 2:05 PM > Subject: [6lowpan] non-technical, but good news to 6lowpanner > Folks, long time no see in IETF. > > I'd forward a good news to 6lowpanner. Our colleagues in 6lowpan WG got > merried. > Eunah and Dominik. > http://home.simula.no/~kaspar/wedding/ch/index.php > > They are also good contributors to 6lowpan standard, and hope their marriage > make them more active in 6lowpan WG. > > Congratulations, and let's have a social party at upcoming IETF if allowed. > > Looking forward to seeing all of you. > > Daniel > -- > Soohong Daniel Park > http://www.soohongp.com > > ________________________________ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > From richard.kelsey@ember.com Sun May 23 14:49:42 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590503A6782 for <6lowpan@core3.amsl.com>; Sun, 23 May 2010 14:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onqaGHJtu9-Z for <6lowpan@core3.amsl.com>; Sun, 23 May 2010 14:49:41 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 5CD383A6768 for <6lowpan@ietf.org>; Sun, 23 May 2010 14:49:41 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 23 May 2010 17:49:33 -0400 Date: Sun, 23 May 2010 17:48:01 -0400 Message-Id: <87eih28f3i.fsf@kelsey-ws.hq.ember.com> To: Carsten Bormann In-reply-to: (message from Carsten Bormann on Tue, 18 May 2010 18:33:24 +0200) From: Richard Kelsey References: <6AAA6AEF-11B3-4342-BEA3-6D6D39E8154C@cs.jhu.edu> <7ED5239F-691E-448D-A174-D6B51128584D@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01E85DBE@XMB-AMS-107.cisco.com><83027ECE5ECDC04E9BA5350B756A88E158D096CBE1@ITR-EXMBXVS-1.itron.com> <4BF28E02.4080000@jennic.com> <6A2A459175DABE4BB11DE2026AA50A5D01E861AF@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 23 May 2010 21:49:33.0622 (UTC) FILETIME=[D49DBD60:01CAFAC1] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] Source Routing Header Format X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sun, 23 May 2010 21:49:42 -0000 [Mailing list switched from roll to 6lowpan, as Carsten's question is for that group.] > From: Carsten Bormann > To: roll@ietf.org > Date: Tue, 18 May 2010 18:33:24 +0200 > > On May 18, 2010, at 18:21, Pascal Thubert (pthubert) wrote: > > > Then 6LoWPAN can work on compressing it using 6LowpAN > > techniques. > > Do we (6LoWPAN) want to? > So far we have focused on compressing things that are very stable. > Tracking a moving target with a compression spec is tedious. I agree that tracking a moving spec is problematic. On the other hand, we know that in the end any source route (or record route) will be a block of IPv6 addresses with a few fields tacked on the front. It should be possible to work on compressing the route itself, which is where the bulk of the compression will be in any case. -Richard Kelsey From zach@sensinode.com Mon May 24 03:39:32 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39CF3A6B11 for <6lowpan@core3.amsl.com>; Mon, 24 May 2010 03:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NydcYLo8K5iO for <6lowpan@core3.amsl.com>; Mon, 24 May 2010 03:39:30 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 5A5783A6B1A for <6lowpan@ietf.org>; Mon, 24 May 2010 03:39:29 -0700 (PDT) Received: from dyn0378.panoulu.local (gw1.panoulu.net [212.50.147.101]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4OAckgn007661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 May 2010 13:39:13 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <87eih28f3i.fsf@kelsey-ws.hq.ember.com> Date: Mon, 24 May 2010 13:38:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8248710D-B263-42E3-9C43-041683F0A7D2@sensinode.com> References: <6AAA6AEF-11B3-4342-BEA3-6D6D39E8154C@cs.jhu.edu> <7ED5239F-691E-448D-A174-D6B51128584D@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01E85DBE@XMB-AMS-107.cisco.com><83027ECE5ECDC04E9BA5350B756A88E158D096CBE1@ITR-EXMBXVS-1.itron.com> <4BF28E02.4080000@jennic.com> <6A2A459175DABE4BB11DE2026AA50A5D01E861AF@XMB-AMS-107.cisco.com> <87eih28f3i.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey X-Mailer: Apple Mail (2.1078) Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] Source Routing Header Format X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 24 May 2010 10:39:32 -0000 On May 24, 2010, at 12:48 AM, Richard Kelsey wrote: > [Mailing list switched from roll to 6lowpan, as Carsten's > question is for that group.] >=20 >> From: Carsten Bormann >> To: roll@ietf.org >> Date: Tue, 18 May 2010 18:33:24 +0200 >>=20 >> On May 18, 2010, at 18:21, Pascal Thubert (pthubert) wrote: >>=20 >>> Then 6LoWPAN can work on compressing it using 6LowpAN >>> techniques.=20 >>=20 >> Do we (6LoWPAN) want to? >> So far we have focused on compressing things that are very stable. >> Tracking a moving target with a compression spec is tedious. >=20 > I agree that tracking a moving spec is problematic. >=20 > On the other hand, we know that in the end any source route > (or record route) will be a block of IPv6 addresses with a > few fields tacked on the front. It should be possible to > work on compressing the route itself, which is where the > bulk of the compression will be in any case. One of the reasons for including next-header-compression (NHC) in HC was = to support future compression of IPv6 extension headers. Therefore if an = RH0 style header would be used for source routing with full IPv6 = addresses, a NHC code could be defined for compressing those addresses. = Note that HC allows other documents to specify such an extension, even = e.g. RPL could do that, so this doesn't necessarily need to be defined = in the 6lowpan WG.=20 Zach >=20 > -Richard Kelsey > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From pthubert@cisco.com Mon May 24 07:30:21 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3B73A6407 for <6lowpan@core3.amsl.com>; Mon, 24 May 2010 07:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.066 X-Spam-Level: X-Spam-Status: No, score=-8.066 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py4jz15beO8K for <6lowpan@core3.amsl.com>; Mon, 24 May 2010 07:30:19 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3F5FF3A6877 for <6lowpan@ietf.org>; Mon, 24 May 2010 07:30:19 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM4p+kurR7Hu/2dsb2JhbACeEXGlSJlOhRME X-IronPort-AV: E=Sophos;i="4.53,291,1272844800"; d="scan'208";a="134098007" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 24 May 2010 14:30:11 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4OEU97Y017709; Mon, 24 May 2010 14:30:11 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 May 2010 16:30:08 +0200 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, 24 May 2010 16:30:03 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01F0CB88@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HC status Thread-Index: Acr7TZi3/XdlWK1bS968E2cUWKzzCA== From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "Richard Kelsey" X-OriginalArrivalTime: 24 May 2010 14:30:08.0054 (UTC) FILETIME=[9BED1560:01CAFB4D] Cc: Carsten Bormann , 6lowpan@ietf.org Subject: [6lowpan] HC status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 24 May 2010 14:30:21 -0000 BTW,=20 do we have a status on the HC draft?=20 We're way past last call aren't we?=20 Did the draft already circulate in higher spheres? Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Zach Shelby > Sent: Monday, May 24, 2010 12:39 PM > To: Richard Kelsey > Cc: Carsten Bormann; 6lowpan@ietf.org > Subject: Re: [6lowpan] [Roll] Source Routing Header Format >=20 >=20 > On May 24, 2010, at 12:48 AM, Richard Kelsey wrote: >=20 > > [Mailing list switched from roll to 6lowpan, as Carsten's > > question is for that group.] > > > >> From: Carsten Bormann > >> To: roll@ietf.org > >> Date: Tue, 18 May 2010 18:33:24 +0200 > >> > >> On May 18, 2010, at 18:21, Pascal Thubert (pthubert) wrote: > >> > >>> Then 6LoWPAN can work on compressing it using 6LowpAN > >>> techniques. > >> > >> Do we (6LoWPAN) want to? > >> So far we have focused on compressing things that are very stable. > >> Tracking a moving target with a compression spec is tedious. > > > > I agree that tracking a moving spec is problematic. > > > > On the other hand, we know that in the end any source route > > (or record route) will be a block of IPv6 addresses with a > > few fields tacked on the front. It should be possible to > > work on compressing the route itself, which is where the > > bulk of the compression will be in any case. >=20 > One of the reasons for including next-header-compression (NHC) in HC was > to support future compression of IPv6 extension headers. Therefore if an > RH0 style header would be used for source routing with full IPv6 addresses, a > NHC code could be defined for compressing those addresses. Note that HC > allows other documents to specify such an extension, even e.g. RPL could do > that, so this doesn't necessarily need to be defined in the 6lowpan WG. >=20 > Zach >=20 > > > > -Richard Kelsey > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From geoff@proto6.com Mon May 24 13:03:10 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2DF3A6F21 for <6lowpan@core3.amsl.com>; Mon, 24 May 2010 13:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.555 X-Spam-Level: X-Spam-Status: No, score=-100.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxGNhSpBnIeD for <6lowpan@core3.amsl.com>; Mon, 24 May 2010 13:03:09 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 687933A6CC9 for <6lowpan@ietf.org>; Mon, 24 May 2010 13:03:09 -0700 (PDT) Received: from server1.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 2663F181EF for <6lowpan@ietf.org>; Mon, 24 May 2010 14:03:04 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o4OK31IL021648 for <6lowpan@ietf.org>; Mon, 24 May 2010 14:03:01 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 24 May 2010 14:03:10 -0600 Message-ID: <1274731390.1719.780.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 24 May 2010 20:03:10 -0000 As there some discussion and changes to the HC draft we will have one more LC for the HC draft. I think think that we need 4 weeks so I proposed that this LC will last one week. This note formally starts the WG Last Call for comments on draft-ietf-6lowpan-hc-07, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks". The document can be found at: http://www.ietf.org/id/draft-ietf-6lowpan-hc-07.txt The document is intended to be submitted by this Working Group to the IESG for publication as a Standards Track document. Please review the document carefully (one last time), and send your comments to the 6lowpan list. Please also indicate in your response whether or not you think this document is ready to go to the IESG. This Last Call will end Wednesday May 31 2010 at 2359 UTC. Thanks, Geoff From whq.amy@gmail.com Tue May 25 17:45:57 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518883A6BEC for <6lowpan@core3.amsl.com>; Tue, 25 May 2010 17:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXX7O2-hBPh3 for <6lowpan@core3.amsl.com>; Tue, 25 May 2010 17:45:56 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 52C6A3A6FB7 for <6lowpan@ietf.org>; Tue, 25 May 2010 17:09:42 -0700 (PDT) Received: by qyk11 with SMTP id 11so8584879qyk.13 for <6lowpan@ietf.org>; Tue, 25 May 2010 17:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=VQ5r8ye1i2/UnYnUk6W0ltYV1pNH6C47UzKwlG015m0=; b=YBdM+MHKDR8zzwpjUH0XgEf7fNjUjnLekfAEgGS4kz9XZlzbklN3vZ1T3YY6p4JqEX FfvH25pFO1G7vz0MlF83aYbBvqAy+55RRhx3j/vgLLLGUAdM6e3xVelFgMDTyuOPALIp TuFgm/QxgarAlG9GmWtsxR+6RCfJB9dzjmaYE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=LsFbQSznNYYXD9aGdzZm6TA4UqCAe+P6Tc/0y4guJUW4u7jxL+nct9BmTN6iU9yJun s6lBCvda+77H7fWecDuEdp6T+wqzX1Q7KoUdGkfT9+UaEgDVuwz24BCLOOz0pLeJIkrN eqpHI2u9eoq7/l2E4uta9ZvMwRgj5ZSzfFkWs= MIME-Version: 1.0 Received: by 10.224.96.166 with SMTP id h38mr4554155qan.199.1274832570877; Tue, 25 May 2010 17:09:30 -0700 (PDT) Received: by 10.229.53.138 with HTTP; Tue, 25 May 2010 17:09:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 May 2010 08:09:30 +0800 Message-ID: From: amy wang To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=00c09f986ac389095804877416fd Subject: [6lowpan] plz plz help with sending uncompressed packets in BLIP X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 26 May 2010 00:45:57 -0000 --00c09f986ac389095804877416fd Content-Type: text/plain; charset=ISO-8859-1 Hi all. As in BLip it uses 6lowpan-hui-hc-00 to compress packets , I want to make the blip also can send no compressed packet. THe dispatch is LOWPAN_IPV6_PATTERN=0x41. I only add some codes in lib6lowpanIP.c/unpackHeaders() and packHeaders(). It can compile but node uploaded can not communicate. Ip-drive on pc do not display the info: INFO: Starting to proxy for 0x1. DO I have to change sth else ? plz give me some help. thx a lot. The code like following : //////////////////////////// packheaders() #ifdef TEST_NOCOMPRESS { *dispatch =LOWPAN_IPV6_PATTERN; ip_memcpy(buf, (uint8_t *)hdr, 40); buf +=40; len -= (buf - dispatch); while (cur != NULL) { if (i==0 && nxt_hdr == IANA_UDP) { if (len < sizeof(struct udp_hdr)) return (buf - dispatch); ip_memcpy(buf, (uint8_t *)cur->hdr.udp, 8); buf +=8; } else{ if (len < cur->len) return 0; ip_memcpy(buf, (uint8_t *)cur->hdr.ext, cur->len); len -= cur->len; buf += cur->len; } cur = cur->next; i++; } //end while } #else ..... ////////////////////////// unpackheader() if (dispatch ==LOWPAN_IPV6_PATTERN){ ip_memcpy(dest, buf, 6); buf += 6; dest += 6; *dest=*buf;buf++; //next header nxt_hdr = dest; dest += 1; *dest = *buf; //hoplimt u_info->hlim = buf; buf++;dest++; ip_memcpy(dest, buf, 32); buf += 32; dest += 32; if (*nxt_hdr==IANA_UDP){ struct udp_hdr *udp1 = (struct udp_hdr *)dest; if (len < sizeof(struct udp_hdr)) return NULL; len -= sizeof(struct udp_hdr); extra_header_length = sizeof(struct udp_hdr); ip_memcpy(dest, buf, 8); buf += 8; dest += 8; u_info->nxt_hdr = IANA_UDP; u_info->payload_offset += sizeof(struct udp_hdr); u_info->transport_ptr = (uint8_t *)udp1; } else{ //not udp,the ipv6 extention header nhdr = *nxt_hdr; u_info->nxt_hdr = nhdr; while (EXTENSION_HEADER(nhdr)) { hdr = (struct ip6_ext *)buf; switch (nhdr) { case IPV6_HOP: u_info->hdr_hop = (struct ip6_ext *)buf; break; case IPV6_ROUTING: u_info->hdr_route = (struct ip6_route *)buf; break; case IPV6_DEST: u_info->hdr_dest = (struct ip6_ext *)buf; break; } nhdr = hdr->nxt_hdr; nhdr_len = hdr->len; u_info->nxt_hdr = nhdr; if (len < nhdr_len) return NULL; ip_memcpy(dest, buf, nhdr_len); dest += nhdr_len; buf += nhdr_len; u_info->payload_offset += nhdr_len; // extra_header_length += nhdr_len; } //while till here u_info->transport_ptr = dest; } //end else u_info->payload_start = buf; u_info->header_end = dest; if (u_info->transport_ptr == NULL) u_info->transport_ptr = dest; } else { ... //hc-00 compress --00c09f986ac389095804877416fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi all.
As in BLip it uses 6lowpan-hui-hc= -00 to compress packets , I want to make the blip also can send no compress= ed packet. THe dispatch is LOWPAN_IPV6_PATTERN=3D0x41.
I only=A0 add som= e codes in=A0 lib6lowpanIP.c/unpackHeaders()=A0=A0 and packHeaders(). It ca= n compile but node uploaded can not communicate.=A0 Ip-drive on pc do not d= isplay the info: INFO: Starting to proxy for 0x1.
DO I have to change sth else ? plz give me some help.
thx a lot.

= The code like following :
////////////////////////////
packheaders()<= br>
#ifdef TEST_NOCOMPRESS
{
=A0 *dispatch =3DLOWPAN_IPV6_PATTERN;=
=A0 ip_memcpy(buf, (uint8_t *)hdr, 40);
=A0 buf +=3D40;
=A0 len -=3D = (buf - dispatch);

=A0 while (cur !=3D NULL) {
=A0=A0=A0=A0=A0 if = (i=3D=3D0 && nxt_hdr =3D=3D IANA_UDP) {
=A0=A0=A0=A0=A0=A0=A0=A0= if (len < sizeof(struct udp_hdr)) return (buf - dispatch);
=A0=A0=A0=A0=A0=A0=A0=A0 ip_memcpy(buf, (uint8_t *)cur->hdr.udp, 8);
= =A0=A0=A0=A0=A0=A0=A0=A0 buf +=3D8;
=A0=A0=A0=A0=A0 }
=A0=A0=A0=A0=A0= else{
=A0=A0=A0=A0=A0=A0=A0=A0 if (len < cur->len) return 0;
= =A0=A0=A0=A0=A0=A0=A0=A0 ip_memcpy(buf, (uint8_t *)cur->hdr.ext, cur->= ;len);
=A0=A0=A0=A0=A0=A0=A0=A0 len -=3D cur->len;
=A0=A0=A0=A0=A0=A0=A0=A0 = buf +=3D cur->len;
=A0=A0=A0=A0=A0 }
=A0=A0=A0=A0=A0 cur =3D cur-&= gt;next;
=A0=A0=A0=A0=A0 i++;
=A0 } //end while
}
#else .....=A0
//////////////////////////
unpackheader()

if (dispatch = =3D=3DLOWPAN_IPV6_PATTERN){
=A0=A0=A0 ip_memcpy(dest, buf, 6);
=A0=A0=A0 buf +=3D 6;=A0=A0
=A0= =A0=A0 dest +=3D 6;

=A0=A0=A0 *dest=3D*buf;buf++; //next header
= =A0=A0=A0 nxt_hdr =3D dest;
=A0=A0=A0 dest +=3D 1;
=A0=A0=A0 *dest = =3D *buf; //hoplimt
=A0=A0=A0 u_info->hlim =3D buf;
=A0=A0=A0 buf+= +;dest++;
=A0=A0=A0 ip_memcpy(dest, buf, 32);
=A0=A0=A0 buf +=3D 32;=A0=A0
=A0= =A0=A0 dest +=3D 32;
=A0=A0=A0 if (*nxt_hdr=3D=3DIANA_UDP){=A0=A0=A0=A0= =A0
=A0=A0=A0=A0=A0 struct udp_hdr *udp1 =3D (struct udp_hdr *)dest;=A0=A0=A0=A0=A0 if (len < sizeof(struct udp_hdr)) return NULL;
=A0=A0=A0=A0=A0 len -=3D sizeof(struct udp_hdr);
=A0=A0=A0=A0=A0 extra_h= eader_length =3D sizeof(struct udp_hdr);
=A0=A0=A0=A0=A0 ip_memcpy(dest,= buf, 8);
=A0=A0=A0=A0=A0 buf +=3D 8;=A0=A0
=A0=A0=A0=A0=A0 dest += =3D 8;
=A0=A0=A0=A0=A0 u_info->nxt_hdr =3D IANA_UDP;
=A0=A0=A0=A0= =A0 u_info->payload_offset +=3D sizeof(struct udp_hdr);
=A0=A0=A0=A0=A0 u_info->transport_ptr =3D (uint8_t *)udp1;

=A0=A0= =A0=A0=A0 }
=A0=A0=A0 else{ //not udp,the ipv6 extention header

= =A0=A0=A0=A0=A0=A0 nhdr =3D *nxt_hdr;
=A0=A0=A0=A0=A0 u_info->nxt_hdr= =3D nhdr;
=A0=A0=A0 while (EXTENSION_HEADER(nhdr)) {
=A0=A0=A0=A0=A0 hdr =3D (struct ip6_ext *)buf;

=A0=A0=A0=A0=A0 switc= h (nhdr) {
=A0=A0=A0=A0=A0 case IPV6_HOP:
=A0=A0=A0=A0=A0=A0=A0 u_inf= o->hdr_hop =3D (struct ip6_ext *)buf;
=A0=A0=A0=A0=A0=A0=A0 break;=A0=A0=A0=A0=A0 case IPV6_ROUTING:
=A0=A0=A0=A0=A0=A0=A0 u_info->hdr= _route =3D (struct ip6_route *)buf;
=A0=A0=A0=A0=A0=A0=A0 break;
=A0=A0=A0=A0=A0 case IPV6_DEST:
=A0=A0= =A0=A0=A0=A0=A0 u_info->hdr_dest =3D (struct ip6_ext *)buf;
=A0=A0=A0= =A0=A0=A0=A0 break;
=A0=A0=A0=A0=A0=A0=A0 }
=A0=A0=A0=A0=A0 nhdr =3D = hdr->nxt_hdr;
=A0=A0=A0=A0=A0 nhdr_len =3D hdr->len;
=A0=A0=A0= =A0=A0 u_info->nxt_hdr =3D nhdr;

=A0=A0=A0=A0=A0 if (len < nhdr_len) return NULL;
=A0=A0=A0=A0=A0 = ip_memcpy(dest, buf, nhdr_len);
=A0=A0=A0=A0=A0 dest +=3D nhdr_len;
= =A0=A0=A0=A0=A0 buf +=3D nhdr_len;

=A0=A0=A0=A0=A0 u_info->payloa= d_offset +=3D nhdr_len;

=A0=A0=A0=A0 // extra_header_length +=3D nhd= r_len;
=A0=A0=A0=A0 } //while till here

=A0=A0=A0=A0 u_info->transport_p= tr =3D dest;
=A0=A0=A0=A0 } //end else

=A0=A0=A0=A0 u_info->pa= yload_start =3D buf;
=A0=A0=A0=A0=A0 u_info->header_end =3D dest;
= =A0=A0=A0=A0 if (u_info->transport_ptr =3D=3D NULL)
=A0=A0=A0=A0=A0=A0=A0 u_info->transport_ptr =3D dest;
=A0 }
else {= ...=A0=A0=A0=A0=A0=A0=A0 //hc-00 compress


--00c09f986ac389095804877416fd-- From geoff@proto6.com Wed May 26 15:20:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B65D3A6A46 for <6lowpan@core3.amsl.com>; Wed, 26 May 2010 15:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC1JvTd1P+Pc for <6lowpan@core3.amsl.com>; Wed, 26 May 2010 15:20:55 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id CCEB03A6A31 for <6lowpan@ietf.org>; Wed, 26 May 2010 15:20:55 -0700 (PDT) Received: from server1.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 3968A18427 for <6lowpan@ietf.org>; Wed, 26 May 2010 16:20:51 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o4QMKkgV008416 for <6lowpan@ietf.org>; Wed, 26 May 2010 16:20:46 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 May 2010 16:20:59 -0600 Message-ID: <1274912459.1629.250.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [6lowpan] clarification X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 26 May 2010 22:20:59 -0000 Folks, It seems that I had typos in my WGLC for the HC draft. In the sentence - "I think think that we need 4 weeks so I proposed that this LC will last one week." what I meant to say was - "I DON'T think that we need 4 weeks so I proposed that this LC will last one week." And I said: "This Last Call will end Wednesday May 31 2010 at 2359 UTC." which if you look at a calendar should be: "This Last Call will end MONDAY May 31 2010 at 2359 UTC." I have not seen any comments for or against this last call. Please speak up if you support this document going forward to the IESG or if you do not (and please tell us why not). geoff From tetsuya@ipinfusion.com Wed May 26 15:22:06 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1833A6A3F for <6lowpan@core3.amsl.com>; Wed, 26 May 2010 15:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeekjtTA+25M for <6lowpan@core3.amsl.com>; Wed, 26 May 2010 15:22:04 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 0E58C3A6A31 for <6lowpan@ietf.org>; Wed, 26 May 2010 15:22:04 -0700 (PDT) Received: by pva18 with SMTP id 18so2217010pva.31 for <6lowpan@ietf.org>; Wed, 26 May 2010 15:21:52 -0700 (PDT) Received: by 10.140.247.18 with SMTP id u18mr7254264rvh.36.1274912512512; Wed, 26 May 2010 15:21:52 -0700 (PDT) Received: from [10.70.2.131] ([12.248.239.142]) by mx.google.com with ESMTPS id b10sm443574rvn.15.2010.05.26.15.21.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 May 2010 15:21:51 -0700 (PDT) From: Tetsuya Murakami Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 26 May 2010 15:21:50 -0700 Message-Id: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> To: 6lowpan@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [6lowpan] SLLA option in NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 26 May 2010 22:22:06 -0000 Hi All, According to the current 6lowpan-nd draft, I have one question. The draft mentioned NS must include SLLA option in order to inform the = link-layer address of the host. However when the router receives RS = message from the host, the router responds RA to the host. At that time, = the router needs to know the link-layer address of the host in order to = send out RA to the host. So, I think SLLA option of the host must be = included in RS instead of NS. According to the current ND draft, after receiving RS message, the = router sends NS message in order to solve the link layer address of the = host by using solicited node multicast address. In order to eliminate = the multicast packet as much as possible, I recommend to include SLLA = option in RS instead of NS. Thanks, Tetsuya Murakami= From samitac@ipinfusion.com Wed May 26 19:23:50 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9583A6A15 for <6lowpan@core3.amsl.com>; Wed, 26 May 2010 19:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.936 X-Spam-Level: X-Spam-Status: No, score=0.936 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_63=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SR8Am9bELkSM for <6lowpan@core3.amsl.com>; Wed, 26 May 2010 19:23:49 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 6B25E3A6899 for <6lowpan@ietf.org>; Wed, 26 May 2010 19:23:47 -0700 (PDT) Received: (qmail 92499 invoked from network); 27 May 2010 02:23:36 -0000 Received: from adsl-71-141-104-10.dsl.snfc21.pacbell.net (samitac@71.141.104.10 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 26 May 2010 19:23:36 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: a5s6hUgVM1nvSqFVLkJoBQapWMW.qfetj_BXSXGRbPoOf1kHTJvoYUnnXQfX0_vL7qoBQO9MxO7MB6Sd9rK410cVUU2AFaOyaCjlPDKBZYcmDXjwa0btane5cCClZIOsPXUopalVdsimKSwJr_Lo_PcF7mWMVxVz2Tujs4wkF_0klSML0PK.xxvFfMCrMCvsB_9zAU5Wv6djjX0XGHTxjzqyJPpyo1HeLAGPXaXJqQtKJ4zTV7Cyoo8bMjdn71eQ X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Tetsuya Murakami'" , <6lowpan@ietf.org> References: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> In-Reply-To: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> Date: Wed, 26 May 2010 19:23:31 -0700 Message-ID: <00b601cafd43$99f95190$cdebf4b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr9IbQNajhgmP/XQBivF6Cmj/AR2QAHP6Bg Content-Language: en-us Subject: Re: [6lowpan] SLLA option in NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 27 May 2010 02:23:50 -0000 Hi Tetsuya, > > The draft mentioned NS must include SLLA option in order to inform the link- > layer address of the host. However when the router receives RS message from > the host, the router responds RA to the host. At that time, the router needs > to know the link-layer address of the host in order to send out RA to the > host. So, I think SLLA option of the host must be included in RS instead of > NS. [SC>] 6lowpan-nd section 5.2 refers to Section 6.3.7 of rfc4861 for sending RS. Rfc4861 States that an implementation SHOULD include SLLA option with RS when the src ip address is not an un-specified address. However, your point is taken and we will discuss this among the co-authors. > > According to the current ND draft, after receiving RS message, the router > sends NS message in order to solve the link layer address of the host by > using solicited node multicast address. In order to eliminate the multicast > packet as much as possible, I recommend to include SLLA option in RS instead > of NS. > [SC>] Actually, if the implementation allows, a router may figure out the link-layer address of the sender of RS from the RS packet(MAC header) and resolve the link-layer address that way. However, in case of 6lowpan devices it might make sense to expect the SLLA option with RS request in order to save some extra processing to figure out from MAC header. [SC>] Thanks, -Samita From robert.cragie@gridmerge.com Thu May 27 11:21:20 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66E033A690E for <6lowpan@core3.amsl.com>; Thu, 27 May 2010 11:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UceidlVISrgC for <6lowpan@core3.amsl.com>; Thu, 27 May 2010 11:21:06 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 1F1983A67A1 for <6lowpan@ietf.org>; Thu, 27 May 2010 11:21:04 -0700 (PDT) Received: from client-82-27-1-244.pete.adsl.virginmedia.com ([82.27.1.244] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OHhhM-0007d0-Td; Thu, 27 May 2010 19:20:53 +0100 Message-ID: <4BFEB800.9070903@gridmerge.com> Date: Thu, 27 May 2010 19:20:48 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Geoff Mulligan References: <1274912459.1629.250.camel@d430> In-Reply-To: <1274912459.1629.250.camel@d430> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050207040508090000050503" Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] clarification X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 18:21:20 -0000 This is a cryptographically signed message in MIME format. --------------ms050207040508090000050503 Content-Type: multipart/alternative; boundary="------------070906080007020104080200" This is a multi-part message in MIME format. --------------070906080007020104080200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Geoff, I have reviewed hc-07 and am happy with it, therefore I support it going = for last call. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 26/05/2010 11:20 PM, Geoff Mulligan wrote: > Folks, > It seems that I had typos in my WGLC for the HC draft. > > In the sentence - "I think think that we need 4 weeks so I proposed tha= t > this LC will last one week." what I meant to say was - "I DON'T think > that we need 4 weeks so I proposed that this LC will last one week." > > And I said: "This Last Call will end Wednesday May 31 2010 at 2359 UTC.= " > which if you look at a calendar should be: "This Last Call will end > MONDAY May 31 2010 at 2359 UTC." > > I have not seen any comments for or against this last call. Please > speak up if you support this document going forward to the IESG or if > you do not (and please tell us why not). > > geoff > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > =20 --------------070906080007020104080200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Geoff,

I have reviewed hc-07 and am happy with it, therefore I support it going for last call.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 26/05/2010 11:20 PM, Geoff Mulligan wrote: 
Folks,
  It seems that I had typos in my WGLC for the HC draft.

In the sentence - "I think think that we need 4 weeks so I proposed that
this LC will last one week." what I meant to say was - "I DON'T think
that we need 4 weeks so I proposed that this LC will last one week."

And I said: "This Last Call will end Wednesday May 31 2010 at 2359 UTC."
which if you look at a calendar should be: "This Last Call will end
MONDAY May 31 2010 at 2359 UTC."

I have not seen any comments for or against this last call.  Please
speak up if you support this document going forward to the IESG or if
you do not (and please tell us why not).

	geoff


_______________________________________________
6lowpan mailing list
6l=
owpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
--------------070906080007020104080200-- --------------ms050207040508090000050503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MjcxODIwNDlaMCMGCSqGSIb3DQEJBDEWBBSwlYooYA1DiP8z7kFFCp5OlKQkIzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBACcU5s1Rcz5P89oYxjXzkET0t1yOmAIcfKyC60Pu62VnpjNDLKYeJSYP4dwFoglmj5dx +DQcjyI2ZIAHnGXjK4PmRGwheb/uTw+Tnx+8N2SjzRH2tfsLzMRylOEuGegLfDz2FM/U6Xh5 x5Lb3O/frdreFe0H5lh/d0DdlfL5r1PlEOLXSRC0SxojGLwalPDudrXrAgV3gD4ux1DpA5i9 Y5OLFMe6vRRyMuyPeBzsdxxAm5ju09jHKKEyYpArjX2pvU/lRlSEWl94n9xGBsatfpz9IrS6 obrLvdxHQNfuRB+c5LtWtHOdllDP4Q1tYU0RhqgVr9ZLHDOSBlb7LrSezugAAAAAAAA= --------------ms050207040508090000050503-- From jreddy@ti.com Thu May 27 21:30:18 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3E63A67FB for <6lowpan@core3.amsl.com>; Thu, 27 May 2010 21:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMEr25FqlXaN for <6lowpan@core3.amsl.com>; Thu, 27 May 2010 21:30:10 -0700 (PDT) Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by core3.amsl.com (Postfix) with ESMTP id 4F8983A67D3 for <6lowpan@ietf.org>; Thu, 27 May 2010 21:30:03 -0700 (PDT) Received: from dlep36.itg.ti.com ([157.170.170.91]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id o4S4TrKU026383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Thu, 27 May 2010 23:29:53 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep36.itg.ti.com (8.13.8/8.13.8) with ESMTP id o4S4TrLY023062 for <6lowpan@ietf.org>; Thu, 27 May 2010 23:29:53 -0500 (CDT) Received: from dlee73.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id o4S4TrZn011647 for <6lowpan@ietf.org>; Thu, 27 May 2010 23:29:53 -0500 (CDT) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee73.ent.ti.com ([157.170.170.88]) with mapi; Thu, 27 May 2010 23:29:52 -0500 From: "Reddy, Joseph" To: "6lowpan@ietf.org" <6lowpan@ietf.org> Date: Thu, 27 May 2010 23:28:07 -0500 Thread-Topic: NS source address in nd-09 Thread-Index: Acr9zt1tJ/3Qp8wzQ76XZq/mY+YXdQATrzvQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [6lowpan] NS source address in nd-09 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 28 May 2010 04:30:18 -0000 Hi ND authors, I have a question on the choice of source address for the NS packets When a new address is to be configured, the draft requires the host to send= NS with with the IPv6 source address set to this address and to also inclu= de ( must ) the SLLA option Does this not cause a violation of the address scoping rules ( since the de= stination address is a link local address derived from the RA while the sou= rce is a global, assuming we want to register a global address ) ? Is there a reason why the unspecified address is not used for the source ( = and include the address in the ARO option ) like in classic ND ? If this is= because you want to include the SLLA option, note that this is not really = necessary since the link layer source address can be deduced by the router = from the L2 headers Also, if a host wants to register with multiple routers, it seems that each= of the routers will end up doing the multihop DaD on the address. This wil= l waste bandwidth ( as well as reduce battery life of host since the proces= s will be much longer ). Instead, it will be useful to allow the host to di= fferentiate between the intial address registration ( when DaD is needed ) = and subsequent ones. One way to do this would be to use the unspecified sou= rce address during initial registration followed by the actual address for = subsequent ones. -Regards, Joseph =20 ------------------------------ Message: 2 Date: Wed, 26 May 2010 15:21:50 -0700 From: Tetsuya Murakami Subject: [6lowpan] SLLA option in NS To: 6lowpan@ietf.org Message-ID: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> Content-Type: text/plain; charset=3Dus-ascii Hi All, According to the current 6lowpan-nd draft, I have one question. The draft mentioned NS must include SLLA option in order to inform the link= -layer address of the host. However when the router receives RS message fro= m the host, the router responds RA to the host. At that time, the router ne= eds to know the link-layer address of the host in order to send out RA to t= he host. So, I think SLLA option of the host must be included in RS instead= of NS. According to the current ND draft, after receiving RS message, the router s= ends NS message in order to solve the link layer address of the host by usi= ng solicited node multicast address. In order to eliminate the multicast pa= cket as much as possible, I recommend to include SLLA option in RS instead = of NS. Thanks, Tetsuya Murakami From erik.nordmark@oracle.com Fri May 28 13:47:08 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90763A695A for <6lowpan@core3.amsl.com>; Fri, 28 May 2010 13:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=1.165, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz1S9dI+SuG5 for <6lowpan@core3.amsl.com>; Fri, 28 May 2010 13:47:07 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id B24BF3A6957 for <6lowpan@ietf.org>; Fri, 28 May 2010 13:47:07 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4SKksaF010946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 May 2010 20:46:56 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4SJuxuw024807; Fri, 28 May 2010 20:46:53 GMT Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 306919921275079530; Fri, 28 May 2010 13:45:30 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 May 2010 13:45:30 -0700 Message-ID: <4C002B66.4010609@oracle.com> Date: Fri, 28 May 2010 13:45:26 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Reddy, Joseph" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090209.4C002BC0.01E1:SCFMA922111,ss=1,fgs=0 Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] NS source address in nd-09 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 28 May 2010 20:47:09 -0000 On 05/27/10 09:28 PM, Reddy, Joseph wrote: > > Hi ND authors, > > I have a question on the choice of source address for the NS packets > > When a new address is to be configured, the draft requires the host > to send NS with with the IPv6 source address set to this address and > to also include ( must ) the SLLA option > > Does this not cause a violation of the address scoping rules ( since > the destination address is a link local address derived from the RA > while the source is a global, assuming we want to register a global > address ) ? There is no prohibition of combining different address scopes in IPv6. RFC 3484 tries to avoid such combinations when the stack needs to select a source/destination path for an application, but that is a different matter. In the 6lowpan-nd case the sender and receiver are neighbors, hence the RFC 3484 considerations don't apply. > Is there a reason why the unspecified address is not used for the > source ( and include the address in the ARO option ) like in classic > ND ? RFC 4861 only allows the unspecified source address in NS message for the purposes of DAD, which is integral to using multicast packets for DAD. Is there a reason to use the unspecified address in some new way? > If this is because you want to include the SLLA option, note > that this is not really necessary since the link layer source address > can be deduced by the router from the L2 headers I think that would be architecturally unsound, because we want IP to be able to run over a rich set of datalink technologies, and over time we have seen datalinks that do odd things to the addresses in the datalink headers. This is now new with IPv6 and ND; arp carries the hardware addresses in the ARP header, even though they are also in the Ethernet header that encapsulates the ARP header. This seemed to have served us well as the Internet has evolved. > Also, if a host wants to register with multiple routers, it seems > that each of the routers will end up doing the multihop DaD on the > address. This will waste bandwidth ( as well as reduce battery life > of host since the process will be much longer ). Instead, it will be > useful to allow the host to differentiate between the intial address > registration ( when DaD is needed ) and subsequent ones. One way to > do this would be to use the unspecified source address during initial > registration followed by the actual address for subsequent ones. A 6LR can trivially tell whether or not it is a re-registration from the host - whether or not it already has a Neighbor Cache entry. If the optional multihop DAD is used, this means that the 6LR can respond immediately to the host for a re-registration. Erik From erik.nordmark@oracle.com Fri May 28 13:56:15 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA6E3A67D7 for <6lowpan@core3.amsl.com>; Fri, 28 May 2010 13:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=0.776, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kibRBszb4eLE for <6lowpan@core3.amsl.com>; Fri, 28 May 2010 13:56:14 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id CDBD43A6806 for <6lowpan@ietf.org>; Fri, 28 May 2010 13:56:14 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4SKu3L5025268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <6lowpan@ietf.org>; Fri, 28 May 2010 20:56:04 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4SIQ9me029626 for <6lowpan@ietf.org>; Fri, 28 May 2010 20:56:02 GMT Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 306939431275080124; Fri, 28 May 2010 13:55:24 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 May 2010 13:55:24 -0700 Message-ID: <4C002DB3.4030202@oracle.com> Date: Fri, 28 May 2010 13:55:15 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <7069.1272031181@marajade.sandelman.ca><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com><005a01caf046$8366a680$8a33f3 80$@stur ek@att.net> <007e01caf16d$4b39aa00$e1acfe00$@com> <6D9687E95918C04A8B30A7D6DA805A3E0142A144@zensys17.zensys.local> <6A2A459175DABE4BB11DE2026AA50A5D01DF4948@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01DF4948@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090202.4C002DE4.014A:SCFMA922111,ss=1,fgs=0 Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 28 May 2010 20:56:15 -0000 On 05/12/10 04:31 AM, Pascal Thubert (pthubert) wrote: > Hi Anders; > > The current ND draft has a white board, though it calls it a neighbor > cache. Sometimes, renaming things is good. In this instance, I do not > know. Clearly, standard neighbor cache entries must not be confused with > the ones gleaned for the registration process, because only the latter > can be fed into the backbone mechanism, be it route over or mesh under. I clarification might be in order. In 6lowpan-nd-09, the only way a neighbor cache entry is created is from the registration process. Thus there isn't any "gleaning" and any risk of conflicts. > The White Board conceptually differs from the traditional Neighbor > Cache: > > - The WB is a table as opposed to a cache. A neighbor cache entry can > stay STALE for a very long time after the node is gone. A neighbor cache > entry can be flushed to make room anytime. So a neighbor cache entry > does not represent the node accurately enough to be redistributed in a > routing protocol or proxied over a backbone. That is true in RFC 4861, but section 6 in 6lowpan-nd-09 tries to make it clear that the entries stay around until they time out. Is there something we should make more clear in that section? > - It is fed proactively using a registration as opposed to reactively to > traffic. The registration and timely reregistration guarantees the > presence of the node proactively. NUD is reactive, depends on traffic. > It is nice to have but not mandatory as long as you have a registration. The purpose of NUD in 6lowpan-nd is primarily to be able to detect when one of the host's default routers have disappeared. Thus I don't see how NUD can not be mandatory; the registration is for the reverse direction - traffic from the router to the host. Erik From geoff@proto6.com Fri May 28 14:26:39 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6243A6806 for <6lowpan@core3.amsl.com>; Fri, 28 May 2010 14:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GUNMTeCQdgf for <6lowpan@core3.amsl.com>; Fri, 28 May 2010 14:26:39 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 16CDB3A67D7 for <6lowpan@ietf.org>; Fri, 28 May 2010 14:26:39 -0700 (PDT) Received: from server1.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 9841218427 for <6lowpan@ietf.org>; Fri, 28 May 2010 15:26:34 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o4SLQSIv023430 for <6lowpan@ietf.org>; Fri, 28 May 2010 15:26:28 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 28 May 2010 15:26:45 -0600 Message-ID: <1275082005.1629.3926.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [6lowpan] HD last call X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 28 May 2010 21:26:39 -0000 Folks, I've only heard from 1 (one, uno, a single) person about the HC draft. This hardly feels like consensus to more forward with the draft. I can assume that Jonathan is a +1 so that would be two (2) people. I'll say that I support it so that is THREE. Please send a note to the list with your thoughts on the HC draft! geoff From joakime@sics.se Fri May 28 15:42:43 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05FDD3A6962 for <6lowpan@core3.amsl.com>; Fri, 28 May 2010 15:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.258 X-Spam-Level: X-Spam-Status: No, score=0.258 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5NZTSmOE-20 for <6lowpan@core3.amsl.com>; Fri, 28 May 2010 15:42:42 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 36C333A695E for <6lowpan@ietf.org>; Fri, 28 May 2010 15:42:42 -0700 (PDT) Received: from [192.168.1.144] (c-cf17e455.013-276-73746f7.cust.bredbandsbolaget.se [85.228.23.207]) (Authenticated sender: joakime@sics.se) by letter.sics.se (Postfix) with ESMTPSA id F25F6400CF; Sat, 29 May 2010 00:42:30 +0200 (CEST) Message-ID: <4C0046DB.7030501@sics.se> Date: Sat, 29 May 2010 00:42:35 +0200 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <1275082005.1629.3926.camel@d430> In-Reply-To: <1275082005.1629.3926.camel@d430> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [6lowpan] HD last call X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 28 May 2010 22:42:43 -0000 +1 from me too! Best regards -- Joakim Eriksson, SICS Geoff Mulligan skrev 2010-05-28 23:26: > Folks, > I've only heard from 1 (one, uno, a single) person about the HC draft. > This hardly feels like consensus to more forward with the draft. > > I can assume that Jonathan is a +1 so that would be two (2) people. > > I'll say that I support it so that is THREE. > > Please send a note to the list with your thoughts on the HC draft! > > geoff > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From jreddy@ti.com Fri May 28 16:30:12 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCAC73A6A60 for <6lowpan@core3.amsl.com>; Fri, 28 May 2010 16:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCBIALSpWW7f for <6lowpan@core3.amsl.com>; Fri, 28 May 2010 16:30:08 -0700 (PDT) Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by core3.amsl.com (Postfix) with ESMTP id 6EEB03A6881 for <6lowpan@ietf.org>; Fri, 28 May 2010 16:30:08 -0700 (PDT) Received: from dlep36.itg.ti.com ([157.170.170.91]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id o4SNTvMV025399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 May 2010 18:29:58 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep36.itg.ti.com (8.13.8/8.13.8) with ESMTP id o4SNTvAb002600; Fri, 28 May 2010 18:29:57 -0500 (CDT) Received: from dlee74.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id o4SNTvii020203; Fri, 28 May 2010 18:29:57 -0500 (CDT) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee74.ent.ti.com ([157.170.170.8]) with mapi; Fri, 28 May 2010 18:29:56 -0500 From: "Reddy, Joseph" To: Erik Nordmark Date: Fri, 28 May 2010 18:29:56 -0500 Thread-Topic: [6lowpan] NS source address in nd-09 Thread-Index: Acr+puvcUmyy5it8S0+SGZKSm6j6HwADL+sw Message-ID: References: <4C002B66.4010609@oracle.com> In-Reply-To: <4C002B66.4010609@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] NS source address in nd-09 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 28 May 2010 23:30:13 -0000 Hi Erik, >> Is there a reason why the unspecified address is not used for the=20 >> source ( and include the address in the ARO option ) like in classic=20 >> ND ? >RFC 4861 only allows the unspecified source address in NS message for the = purposes of DAD, which is integral to using multicast packets for DAD. >Is there a reason to use the unspecified address in some new way? [JSR] The reason would be the handling of neighbor cache on the parent router. In= the current draft, it is possible that an inaccurate neigbor cache entry i= s temporarily created on a Router and that could lead to potential problems= . Consider a scenario where Host1 registers its address with Router1 and succ= esfully undergoes multihop DaD Now suppose Host2 attempts to register the same IP address with Router2. Wh= ile the multihop DaD is ongoing, Router2 will have a neighbor cache entry w= ith the duplicate IP address ( that actually belongs to Host1 ) and the LL = address of Host2 ( note that is necessary for the Router2 to create a neigh= bor cache entry at this stage, otherwise the SLLA of Host2 would not be ava= ilable later to send the NA ). Now lets say that Host2 were to lose connectivity to its default Router1 an= d it tries to register with a differnet router, say Router2. It will get a = duplicate address message from Router2, even though it actually owns the ad= dress. -Regards, Joseph -----Original Message----- From: Erik Nordmark [mailto:erik.nordmark@oracle.com]=20 Sent: Friday, May 28, 2010 1:45 PM To: Reddy, Joseph Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] NS source address in nd-09 On 05/27/10 09:28 PM, Reddy, Joseph wrote: > > Hi ND authors, > > I have a question on the choice of source address for the NS packets > > When a new address is to be configured, the draft requires the host to=20 > send NS with with the IPv6 source address set to this address and to=20 > also include ( must ) the SLLA option > > Does this not cause a violation of the address scoping rules ( since=20 > the destination address is a link local address derived from the RA=20 > while the source is a global, assuming we want to register a global=20 > address ) ? There is no prohibition of combining different address scopes in IPv6.=20 RFC 3484 tries to avoid such combinations when the stack needs to select a = source/destination path for an application, but that is a different matter. In the 6lowpan-nd case the sender and receiver are neighbors, hence the RFC= 3484 considerations don't apply. > Is there a reason why the unspecified address is not used for the=20 > source ( and include the address in the ARO option ) like in classic=20 > ND ? RFC 4861 only allows the unspecified source address in NS message for the p= urposes of DAD, which is integral to using multicast packets for DAD. Is there a reason to use the unspecified address in some new way? > If this is because you want to include the SLLA option, note that this=20 > is not really necessary since the link layer source address can be=20 > deduced by the router from the L2 headers I think that would be architecturally unsound, because we want IP to be abl= e to run over a rich set of datalink technologies, and over time we have se= en datalinks that do odd things to the addresses in the datalink headers. T= his is now new with IPv6 and ND; arp carries the hardware addresses in the = ARP header, even though they are also in the Ethernet header that encapsula= tes the ARP header. This seemed to have served us well as the Internet has = evolved. > Also, if a host wants to register with multiple routers, it seems that=20 > each of the routers will end up doing the multihop DaD on the address.=20 > This will waste bandwidth ( as well as reduce battery life of host=20 > since the process will be much longer ). Instead, it will be useful to=20 > allow the host to differentiate between the intial address=20 > registration ( when DaD is needed ) and subsequent ones. One way to do=20 > this would be to use the unspecified source address during initial=20 > registration followed by the actual address for subsequent ones. A 6LR can trivially tell whether or not it is a re-registration from the ho= st - whether or not it already has a Neighbor Cache entry. If the optional multihop DAD is used, this means that the 6LR can respond i= mmediately to the host for a re-registration. Erik From coflynn@newae.com Sat May 29 01:54:39 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B670E3A6826 for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 01:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2v9cQa+jIKj for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 01:54:39 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id E922C3A67AC for <6lowpan@ietf.org>; Sat, 29 May 2010 01:54:38 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OIHoJ-0002VS-Fd for 6lowpan@ietf.org; Sat, 29 May 2010 04:54:27 -0400 From: "Colin O'Flynn" To: <6lowpan@ietf.org> References: <1275082005.1629.3926.camel@d430> <4C0046DB.7030501@sics.se> In-Reply-To: <4C0046DB.7030501@sics.se> Date: Sat, 29 May 2010 09:54:12 +0100 Message-ID: <000f01caff0c$8517a450$8f46ecf0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr+txGGHAOUPzSqTnapi88nLLhLeAAVWXpA Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] HD last call X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 29 May 2010 08:54:39 -0000 +1 from me too. -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Joakim Eriksson Sent: May 28, 2010 11:43 PM To: 6lowpan@ietf.org Subject: Re: [6lowpan] HD last call +1 from me too! Best regards -- Joakim Eriksson, SICS Geoff Mulligan skrev 2010-05-28 23:26: > Folks, > I've only heard from 1 (one, uno, a single) person about the HC draft. > This hardly feels like consensus to more forward with the draft. > > I can assume that Jonathan is a +1 so that would be two (2) people. > > I'll say that I support it so that is THREE. > > Please send a note to the list with your thoughts on the HC draft! > > geoff > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From robert.cragie@gridmerge.com Sat May 29 04:25:44 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426E03A684C for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 04:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.27 X-Spam-Level: X-Spam-Status: No, score=-0.27 tagged_above=-999 required=5 tests=[AWL=1.469, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rDfMy+l0vOM for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 04:25:42 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 8E43C3A68DB for <6lowpan@ietf.org>; Sat, 29 May 2010 04:25:41 -0700 (PDT) Received: from client-82-26-176-40.pete.adsl.virginmedia.com ([82.26.176.40] helo=[192.168.1.71]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OIKAM-000063-NV; Sat, 29 May 2010 12:25:23 +0100 Message-ID: <4C00F99D.9020209@gridmerge.com> Date: Sat, 29 May 2010 12:25:17 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Reddy, Joseph" References: <4C002B66.4010609@oracle.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060900070207000204050707" Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] NS source address in nd-09 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 11:25:44 -0000 This is a cryptographically signed message in MIME format. --------------ms060900070207000204050707 Content-Type: multipart/alternative; boundary="------------080408090406090202010204" This is a multi-part message in MIME format. --------------080408090406090202010204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Joseph, Comments inline, bracketed by Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 29/05/2010 12:29 AM, Reddy, Joseph wrote: > Hi Erik, > > =20 >>> Is there a reason why the unspecified address is not used for the >>> source ( and include the address in the ARO option ) like in classic >>> ND ? >>> =20 > =20 >> RFC 4861 only allows the unspecified source address in NS message for = the purposes of DAD, which is integral to using multicast packets for DAD= =2E >> =20 > =20 >> Is there a reason to use the unspecified address in some new way? >> =20 > [JSR] > The reason would be the handling of neighbor cache on the parent router= =2E In the current draft, it is possible that an inaccurate neigbor cache= entry is temporarily created on a Router and that could lead to potentia= l problems. > > Consider a scenario where Host1 registers its address with Router1 and = succesfully undergoes multihop DaD > > Now suppose Host2 attempts to register the same IP address with Router2= =2E While the multihop DaD is ongoing, Router2 will have a neighbor cache= entry with the duplicate IP address ( that actually belongs to Host1 ) a= nd the LL address of Host2 ( note that is necessary for the Router2 to cr= eate a neighbor cache entry at this stage, otherwise the SLLA of Host2 wo= uld not be available later to send the NA ). > =20 Maybe it's missing from the spec. but the neighbor cache entry must = be marked as tentative somehow until registration and multihop DAD is=20 complete. > Now lets say that Host2 were to lose connectivity to its default Router= 1 and it tries to register with a differnet router, say Router2. It will = get a duplicate address message from Router2, even though it actually own= s the address. > =20 Do you mean Host1? Again, if DAD isn't complete I would presume=20 that Router2 cannot assume any validity about Host2 until it has=20 completed its DAD. In the above scenario, Host2 would fail its DAD,=20 therefore would have to register a different address. > > > -Regards, Joseph > > > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@oracle.com] > Sent: Friday, May 28, 2010 1:45 PM > To: Reddy, Joseph > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] NS source address in nd-09 > > On 05/27/10 09:28 PM, Reddy, Joseph wrote: > =20 >> Hi ND authors, >> >> I have a question on the choice of source address for the NS packets >> >> When a new address is to be configured, the draft requires the host to= >> send NS with with the IPv6 source address set to this address and to >> also include ( must ) the SLLA option >> >> Does this not cause a violation of the address scoping rules ( since >> the destination address is a link local address derived from the RA >> while the source is a global, assuming we want to register a global >> address ) ? >> =20 > There is no prohibition of combining different address scopes in IPv6. > RFC 3484 tries to avoid such combinations when the stack needs to selec= t a source/destination path for an application, but that is a different m= atter. > In the 6lowpan-nd case the sender and receiver are neighbors, hence the= RFC 3484 considerations don't apply. > > =20 >> Is there a reason why the unspecified address is not used for the >> source ( and include the address in the ARO option ) like in classic >> ND ? >> =20 > RFC 4861 only allows the unspecified source address in NS message for t= he purposes of DAD, which is integral to using multicast packets for DAD.= > > Is there a reason to use the unspecified address in some new way? > > =20 >> If this is because you want to include the SLLA option, note that this= >> is not really necessary since the link layer source address can be >> deduced by the router from the L2 headers >> =20 > I think that would be architecturally unsound, because we want IP to be= able to run over a rich set of datalink technologies, and over time we h= ave seen datalinks that do odd things to the addresses in the datalink he= aders. This is now new with IPv6 and ND; arp carries the hardware address= es in the ARP header, even though they are also in the Ethernet header th= at encapsulates the ARP header. This seemed to have served us well as the= Internet has evolved. > > =20 >> Also, if a host wants to register with multiple routers, it seems that= >> each of the routers will end up doing the multihop DaD on the address.= >> This will waste bandwidth ( as well as reduce battery life of host >> since the process will be much longer ). Instead, it will be useful to= >> allow the host to differentiate between the intial address >> registration ( when DaD is needed ) and subsequent ones. One way to do= >> this would be to use the unspecified source address during initial >> registration followed by the actual address for subsequent ones. >> =20 > A 6LR can trivially tell whether or not it is a re-registration from th= e host - whether or not it already has a Neighbor Cache entry. > If the optional multihop DAD is used, this means that the 6LR can respo= nd immediately to the host for a re-registration. > > Erik > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > =20 --------------080408090406090202010204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Joseph,

Comments inline, bracketed by <RCC></RCC>

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 29/05/2010 12:29 AM, Reddy, Joseph wrote: 
Hi Erik,

  
Is there a reason why the unspecified address is not=
 used for the=20
source ( and include the address in the ARO option ) like in classic=20
ND ?
      
  
RFC 4861 only allows the unspecified source address in=
 NS message for the purposes of DAD, which is integral to using multicast=
 packets for DAD.
    
  
Is there a reason to use the unspecified address in so=
me new way?
    
[JSR]
The reason would be the handling of neighbor cache on the parent router. =
In the current draft, it is possible that an inaccurate neigbor cache ent=
ry is temporarily created on a Router and that could lead to potential pr=
oblems.

Consider a scenario where Host1 registers its address with Router1 and su=
ccesfully undergoes multihop DaD

Now suppose Host2 attempts to register the same IP address with Router2. =
While the multihop DaD is ongoing, Router2 will have a neighbor cache ent=
ry with the duplicate IP address ( that actually belongs to Host1 ) and t=
he LL address of Host2 ( note that is necessary for the Router2 to create=
 a neighbor cache entry at this stage, otherwise the SLLA of Host2 would =
not be available later to send the NA ).
<RCC>Maybe it's missing from the spec. but the neighbor cache entry must be marked as tentative somehow until registration and multihop DAD is complete.</RCC>
Now lets say that Host2 were to lose connectivity to its default Router1 =
and it tries to register with a differnet router, say Router2. It will ge=
t a duplicate address message from Router2, even though it actually owns =
the address.
<RCC>Do you mean Host1? Again, if DAD isn't complete I would presume that Router2 cannot assume any validity about Host2 until it has completed its DAD. In the above scenario, Host2 would fail its DAD, therefore would have to register a different address.</RCC>


-Regards, Joseph


-----Original Message-----
From: Erik Nordmark [mailto:erik.nordmark@oracle.com]=20
Sent: Friday, May 28, 2010 1:45 PM
To: Reddy, Joseph
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] NS source address in nd-09

On 05/27/10 09:28 PM, Reddy, Joseph wrote:
  
Hi ND authors,

I have a question on the choice of source address for the NS packets

When a new address is to be configured, the draft requires the host to=20
send NS with with the IPv6 source address set to this address and to=20
also include ( must ) the SLLA option

Does this not cause a violation of the address scoping rules ( since=20
the destination address is a link local address derived from the RA=20
while the source is a global, assuming we want to register a global=20
address ) ?
    
There is no prohibition of combining different address scopes in IPv6.=20
RFC 3484 tries to avoid such combinations when the stack needs to select =
a source/destination path for an application, but that is a different mat=
ter.
In the 6lowpan-nd case the sender and receiver are neighbors, hence the R=
FC 3484 considerations don't apply.

  
Is there a reason why the unspecified address is not u=
sed for the=20
source ( and include the address in the ARO option ) like in classic=20
ND ?
    
RFC 4861 only allows the unspecified source address in NS message for the=
 purposes of DAD, which is integral to using multicast packets for DAD.

Is there a reason to use the unspecified address in some new way?

  
If this is because you want to include the SLLA option=
, note that this=20
is not really necessary since the link layer source address can be=20
deduced by the router from the L2 headers
    
I think that would be architecturally unsound, because we want IP to be a=
ble to run over a rich set of datalink technologies, and over time we hav=
e seen datalinks that do odd things to the addresses in the datalink head=
ers. This is now new with IPv6 and ND; arp carries the hardware addresses=
 in the ARP header, even though they are also in the Ethernet header that=
 encapsulates the ARP header. This seemed to have served us well as the I=
nternet has evolved.

  
Also, if a host wants to register with multiple router=
s, it seems that=20
each of the routers will end up doing the multihop DaD on the address.=20
This will waste bandwidth ( as well as reduce battery life of host=20
since the process will be much longer ). Instead, it will be useful to=20
allow the host to differentiate between the intial address=20
registration ( when DaD is needed ) and subsequent ones. One way to do=20
this would be to use the unspecified source address during initial=20
registration followed by the actual address for subsequent ones.
    
A 6LR can trivially tell whether or not it is a re-registration from the =
host - whether or not it already has a Neighbor Cache entry.
If the optional multihop DAD is used, this means that the 6LR can respond=
 immediately to the host for a re-registration.

    Erik
_______________________________________________
6lowpan mailing list
6l=
owpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
--------------080408090406090202010204-- --------------ms060900070207000204050707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MjkxMTI1MTdaMCMGCSqGSIb3DQEJBDEWBBQn3NDo5MknvU9vyzJIJIDha8eECDBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBACQG3EcawNugUU8aPfVTu+UAXLwNwE3iI2O+USiUdCZT6dZ3+stBp0KM9f/uBOyf1UEY yfEb3aM5flJoB7jPHHMmPXagcSBvVRJq36LPfO8lSqhjWenm3YChh/zj00gdYMzvZfl8h2wo MXAaq92Asxdrq568eR6VNGFUKWKFfHOD2Hj1rluASqt9nyrgyywzknBb8N9RSn7rpa5CUFRY +7tBFd/CH6m3OzHD4HtchCTd0xQqyJoPyJIKPiJRmEgKuYDmouyr/ifqulpZCKEeHtnT2dLN 7cpDb5YuIuyol8o+zqIfoXcanwWYNW2Nnv7rMe1SKI+vcJhnCEoCVKu3m6UAAAAAAAA= --------------ms060900070207000204050707-- From zach@sensinode.com Sat May 29 04:39:00 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 759943A69DB for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 04:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFVuLZJOmyAs for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 04:38:58 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 7D0D03A684C for <6lowpan@ietf.org>; Sat, 29 May 2010 04:38:57 -0700 (PDT) Received: from [192.168.1.3] (line-8012.dyn.kponet.fi [85.29.77.170]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4TBcgHP013699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 29 May 2010 14:38:42 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <1275082005.1629.3926.camel@d430> Date: Sat, 29 May 2010 14:38:43 +0300 Content-Transfer-Encoding: 7bit Message-Id: <40CF32BF-9887-4F98-968F-0A4B43CE301E@sensinode.com> References: <1275082005.1629.3926.camel@d430> To: Geoff Mulligan X-Mailer: Apple Mail (2.1078) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] HD last call X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 29 May 2010 11:39:00 -0000 I have reviewed hc-07 and am happy with it. Zach On May 29, 2010, at 12:26 AM, Geoff Mulligan wrote: > Folks, > I've only heard from 1 (one, uno, a single) person about the HC draft. > This hardly feels like consensus to more forward with the draft. > > I can assume that Jonathan is a +1 so that would be two (2) people. > > I'll say that I support it so that is THREE. > > Please send a note to the list with your thoughts on the HC draft! > > geoff > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac@tools.ietf.org Sat May 29 04:56:22 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38F353A677D for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 04:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.596 X-Spam-Level: X-Spam-Status: No, score=-101.596 tagged_above=-999 required=5 tests=[AWL=1.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er9IYlpUZgGM for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 04:56:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8FD723A6A10 for <6lowpan@ietf.org>; Sat, 29 May 2010 04:56:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OIKeB-0007hf-9K; Sat, 29 May 2010 04:56:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sat, 29 May 2010 11:56:11 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/66 Message-ID: <060.a0a51b549dd37daab824974892493632@tools.ietf.org> X-Trac-Ticket-ID: 66 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #66: Clarification of Section 8.2 assumptions X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 11:56:22 -0000 #66: Clarification of Section 8.2 assumptions --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- The optional Section 8.2 DAD mechanism requires that the DAD tables of all 6LBRs advertising the same prefix are checked for duplicates in order to work correctly. Currently the text is not clear enough about that, and the following text should be added to the end of the first paragraph of Section 8.2 and to the Section 1.3 assumptions: "This assumes that the 6LRs either register with all the 6LBRs, or that the network uses some out-of-scope mechanism to keep the 6LBRs synchronized." -- Ticket URL: 6lowpan From trac@tools.ietf.org Sat May 29 05:16:26 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6863A6AA4 for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 05:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.68 X-Spam-Level: X-Spam-Status: No, score=-101.68 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RXQNccm6nOW for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 05:16:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B02223A6A9D for <6lowpan@ietf.org>; Sat, 29 May 2010 05:16:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OIKxY-0005iT-Dl; Sat, 29 May 2010 05:16:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sat, 29 May 2010 12:16:12 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/67 Message-ID: <060.76e1f6097caf12e27d365e771a0fe7d8@tools.ietf.org> X-Trac-Ticket-ID: 67 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #67: Clarfication about the Neighbor Cache X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 12:16:26 -0000 #67: Clarfication about the Neighbor Cache --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Pascal commented on the list that the Neighbor Cache is used differently than in RFC4861 thus it should have a different name etc. The use of Neighbor Cache in nd-09 is however 80-90% common to the use in RFC4861 so the Neighbor Cache name should be kept and as a single cache. The maintenance of entries in the nd-09 Neighbor Cache is based on address registration with the lifetime set buy the host, thus the following text will be added to clarify the difference in the terminology under registration and in Section 5.5: "Thus for 6LoWPAN the Neighbor Cache doesn't behave like a cache. Instead it behaves as a registry of all the host addresses that are attached to the Router." -- Ticket URL: 6lowpan From trac@tools.ietf.org Sat May 29 05:33:18 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4603A6A9D for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 05:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.751 X-Spam-Level: X-Spam-Status: No, score=-101.751 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82-II0YsZiPl for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 05:33:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8A9003A68D3 for <6lowpan@ietf.org>; Sat, 29 May 2010 05:33:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OILDv-0004d5-6M; Sat, 29 May 2010 05:33:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sat, 29 May 2010 12:33:07 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/68 Message-ID: <060.fe2bdc40f04a8c15333042ebfb94ba7c@tools.ietf.org> X-Trac-Ticket-ID: 68 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #68: SLLA Option in RS and NS messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 12:33:18 -0000 #68: SLLA Option in RS and NS messages --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Tetsuya and Joseph brought up an issue on the list to clarify the inclusion of the SLLA Option in RS and NS messages and the point at which a Neighbor Cache entry is made. The following clarfications are planned: - The SLLA Option MUST be included in both RS and NS messages. - The RA must use the SLLA option in the RS without creating a Neighbor Cache entry, because we don't want to add a Neighbor Cache entry until we get an ARO from the host. - Clarify that an unspecified source address is never used for a NS. -- Ticket URL: 6lowpan From trac@tools.ietf.org Sat May 29 05:44:50 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615D43A6AC2 for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 05:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.811 X-Spam-Level: X-Spam-Status: No, score=-101.811 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCqNRCM-o4AW for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 05:44:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 694DA3A6AC1 for <6lowpan@ietf.org>; Sat, 29 May 2010 05:44:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OILP4-000545-D5; Sat, 29 May 2010 05:44:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sat, 29 May 2010 12:44:38 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/69 Message-ID: <060.5055baccc657af3b7ef73329644670d0@tools.ietf.org> X-Trac-Ticket-ID: 69 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #69: Add term 6LoWPAN Node (6LN) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 12:44:50 -0000 #69: Add term 6LoWPAN Node (6LN) --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- -- Ticket URL: 6lowpan From trac@tools.ietf.org Sat May 29 06:06:57 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AD743A6AC5 for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 06:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.864 X-Spam-Level: X-Spam-Status: No, score=-101.864 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjeLls6BRRrk for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 06:06:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7759A3A6AC4 for <6lowpan@ietf.org>; Sat, 29 May 2010 06:06:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OILkU-0008QJ-4k; Sat, 29 May 2010 06:06:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sat, 29 May 2010 13:06:46 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/70 Message-ID: <060.7339538cb45b06b61823622ecdcf011e@tools.ietf.org> X-Trac-Ticket-ID: 70 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #70: Clarification on the 6CO C flag X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 13:06:57 -0000 #70: Clarification on the 6CO C flag --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- From Robert Cragie: page 16: C: 1-bit context compression flag - I would add the proposed text at the end of the definition to make it clear what this flag is for: "This flag is used to manage the context lifecycle based on the recommendations in Section 7.2" -- Ticket URL: 6lowpan From zach@sensinode.com Sat May 29 06:07:57 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626053A6AC3 for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 06:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8hN7eMAkfg1 for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 06:07:55 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 1B2023A6ABC for <6lowpan@ietf.org>; Sat, 29 May 2010 06:07:54 -0700 (PDT) Received: from [192.168.1.3] (line-8012.dyn.kponet.fi [85.29.77.170]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4TD7bsn014749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 29 May 2010 16:07:38 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4BED6B9B.1060305@gridmerge.com> Date: Sat, 29 May 2010 16:07:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BED6B9B.1060305@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1078) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Comments on draft-ietf-6lowpan-nd-09 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 29 May 2010 13:07:57 -0000 Hi Robert, Thanks for the comments, below you'll find merged comments from the = authors. On the nit and grammar related comments I will check those = though while doing editing on nd-10 so don't be bothered that I skip = them below. We have started creating tickets on changes in progress for = nd-10. On May 14, 2010, at 6:26 PM, Robert Cragie wrote: > page 7: >=20 > "EUI-64s are globally unique" - What about the case of spoofed/cloned = EUI-64s? What would be the effect using this ND? Would it be = significant? My guess is probably not but it might be worth making this = clear We decided it might take a whole bunch of text to discuss all the issues = that might happen with duplicate EUI-64s. For this spec we simply assume = that EUI-64s are unique thus we don't try to detect duplicates. > page 8: >=20 > "However, the Address Registration mechanism might be useful for other = link layer technologies" - I would have thought all the mechanisms and = modifications may apply to other link layer technologies That should read "this specification" might be useful...=20 >=20 > page 9: >=20 > The process during which a LoWPAN node sends an Neighbor Solicitation = message - Is "LoWPAN node" a specific term? If so, needs to be defined. = I would also suggest it is called 6LoWPAN Node (6LN?) to be consistent >=20 > "that allows for sleeping nodes" - 6LoWPAN nodes? Check for this = throughout the document I added a ticket to add the term 6LN. >=20 > "initial set of default routers" - This might seem pedantic, but = "Router" (with an uppercase R) is defined in this document and "router" = (with a lowercase r) is defined in RFC4861 and they are subtly = different. Maybe have this consistency across the document We'll try to improve consistency.=20 >=20 > page 10: >=20 > "which in turn use normal Neighbor Discovery mechanisms to convey this = information to the hosts" - I think this is questionable; there are some = differences >=20 > "DAD is optional if DHCPv6 is used to assign addresses" - Or an = alternative address assignment mechanism We don't know of alternative assignment mechanisms, so let's just talk = about DHCPv6 in this draft. >=20 > page 12: >=20 > "In this case, the Neighbor Solicitation and Advertisement messages = will be forwarded between the 6LR and 6LBRs" - This is overloading the = original use of NS/NA as defined in RFC4861 quite a lot and changing the = rules. There seemed to be resistance to defining a new message but = wouldn't that actually be better? This was the approach in earlier versions of 6lowpan-nd with Neighbor = Registration/Confirmation, but for this draft we chose to use NS/NA = across the board for simplicity, although what you suggest has been = discussed. Let's keep using the same NS/NA message in Section 8.2 as for = the base registration for now unless people run into major = implementation problems or we get IESG comments on this. This is = something we should keep in mind though. > page 16: >=20 > C: 1-bit context compression flag - I would add the proposed text at = the end of the definition to make it clear what this flag is for: "This = flag is used to manage the context lifecycle based on the = recommendations in Section 7.2" Thanks, ticket added. >=20 > page 18: >=20 > "and sent to the IPv6 All-Routers multicast address" - There is also a = case for being able to send unicast as it is possible the host has = discovered which router it wishes to join the network through by other = means, e.g. 802.15.4 beacon request. This could potentially limit = traffic. Section 5.8.2 also says it can be sent unicast. Will look into this. >=20 > page 19: >=20 > "This includes the Context ID, the prefix" - Possibly some confusion = between the context prefix and the prefix in the PIO. Maybe clarfication = on the terminology is needed. Will try to clarify overall. >=20 > page 21: >=20 > "or the appropriate IP-over-foo document" - Is this a well-known = phrase in the IETF community? :-) Yes ;-) >=20 > page 25: >=20 > "then care should be taken to ensure that there isn't a flood of = ARO-carrying messages **sent** to the 6LBR as each router hears an ARO = from their neighboring routers" - Is this likely to happen with a = unicast to 6LBR? (** typo 'send' -> 'sent' **) Some proposals are currently being considered for limiting the amount of = NSs. >=20 > page 28: >=20 > "then the RA MUST be silently ignored" - "Silently ignored" is a = tautology. Either "silently discarded" or simply "ignored" Silently ignored is more common in IETF terminology. >=20 > page 29: >=20 > "The routers periodically send Router Advertisements" - "may = periodically send"? It is optional, isn't it? Also might be worth = mentioning this information could be disseminated by other mechanisms. Periodic sending is a must for Section 8.1 to ensure new information is = disseminated. Section 8.1 already makes it clear that this mechanism is = optional and e.g. a routing protocol might already do this.=20 >=20 > page 30: >=20 > 8.2.1. Special Message Validation - This is a rather complex rule for = NS/NA processing as the hop limit processing may well happen before = payload processing. Could it be made simpler or more logical? We didn't find anything particularly hard there.=20 >=20 > page 31: >=20 > "It proceeds to look for the Registration Address in the DAD Table. = If an entry is found and the recorded EUI-64 is different than the = EUI-64 in the ARO, then it returns an NA with the ARO Status set to 1 = ('Duplicate Address'). Otherwise it returns an NA with ARO Status set = to zero." - It would be really nice if it could also return a 'suggested = address'. This would complete address assignment without the host having = to guess again. We had the ability to request an address in previous nd versions, but = that was removed due to push-back from people thinking that the point = here was address assignment (which it was not). We don't think it is = wise to start adding that kind of feature here again (although = personally I would find it useful). In the end, this process is only = done the first time a node registers a short address on the LoWPAN so = the overhead from trying again in case of a duplicate should not be = significant.=20 Zach >=20 > --=20 > Robert Cragie (Pacific Gas & Electric) >=20 > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac@tools.ietf.org Sat May 29 06:09:47 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30DC73A6928 for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 06:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.91 X-Spam-Level: X-Spam-Status: No, score=-101.91 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp5sB0m-atgD for <6lowpan@core3.amsl.com>; Sat, 29 May 2010 06:09:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6CE463A67E6 for <6lowpan@ietf.org>; Sat, 29 May 2010 06:09:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OILnE-00015Z-Fe; Sat, 29 May 2010 06:09:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sat, 29 May 2010 13:09:36 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/68#comment:1 Message-ID: <069.65f93cf532abf77a6201f40a2f7828ea@tools.ietf.org> References: <060.fe2bdc40f04a8c15333042ebfb94ba7c@tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <060.fe2bdc40f04a8c15333042ebfb94ba7c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #68: SLLA Option in RS and NS messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 13:09:47 -0000 #68: SLLA Option in RS and NS messages --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Changes (by zach@…): * component: format => nd -- Ticket URL: 6lowpan From erik.nordmark@oracle.com Sun May 30 05:51:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A623A67FF for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 05:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhg4msbonSW5 for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 05:51:57 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 501623A6843 for <6lowpan@ietf.org>; Sun, 30 May 2010 05:51:55 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4UCpgXZ026883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 May 2010 12:51:43 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4UA9IR8026858; Sun, 30 May 2010 12:51:41 GMT Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 280877351275223873; Sun, 30 May 2010 05:51:13 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 30 May 2010 05:51:12 -0700 Message-ID: <4C025F1C.7080806@oracle.com> Date: Sun, 30 May 2010 05:50:36 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Reddy, Joseph" References: <4C002B66.4010609@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090201.4C025F60.0036:SCFMA922111,ss=1,fgs=0 Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] NS source address in nd-09 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sun, 30 May 2010 12:51:58 -0000 On 05/28/10 04:29 PM, Reddy, Joseph wrote: > > Hi Erik, > >>> Is there a reason why the unspecified address is not used for >>> the source ( and include the address in the ARO option ) like in >>> classic ND ? > >> RFC 4861 only allows the unspecified source address in NS message >> for the purposes of DAD, which is integral to using multicast >> packets for DAD. > >> Is there a reason to use the unspecified address in some new way? > > [JSR] The reason would be the handling of neighbor cache on the > parent router. In the current draft, it is possible that an > inaccurate neigbor cache entry is temporarily created on a Router and > that could lead to potential problems. > > Consider a scenario where Host1 registers its address with Router1 > and succesfully undergoes multihop DaD > > Now suppose Host2 attempts to register the same IP address with > Router2. While the multihop DaD is ongoing, Router2 will have a > neighbor cache entry with the duplicate IP address ( that actually > belongs to Host1 ) and the LL address of Host2 ( note that is > necessary for the Router2 to create a neighbor cache entry at this > stage, otherwise the SLLA of Host2 would not be available later to > send the NA ). I see some more care is needed in the specification around multihop DAD. In the case of multihop DAD I don't think the 6LR should create a Neighbor Cache entry until DAD has been verified. A possible way to handle not forgetting the SLLA (to be able to respond as you point out) would be to create a NCE but mark it as "unverified". Then an unverified NCE can be be used to send the response to the host, and if the response was "ok" then the unverified NCE would become a normal NCE, otherwise it would be deleted. This means that in the case of two hosts attached to the same 6LR try to use the same IP address at the same time, then the 6LR might end up with two unverified NCEs for the same IP address; at most one of those will "win" as determined by the 6LBR(s). Thus when a response comes from the 6LBR the 6LR will use the IPv6 address plus the EUI-64 to find any "unverified" NCE. In any case, I don't see how using the unspecified source address would make this any easier. The fundamental issue is that an 6LR needs to retain sufficient information about a host while multihop DAD is in progress, and not let that "in progress" information be confused with authoritative and verified registrations. Erik From erik.nordmark@oracle.com Sun May 30 06:10:18 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4A73A685C for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 06:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuZfJyL4aDxd for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 06:10:14 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 8A15A3A6892 for <6lowpan@ietf.org>; Sun, 30 May 2010 06:10:12 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4UD9veg007946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 May 2010 13:09:58 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4UD9t7K013528; Sun, 30 May 2010 13:09:56 GMT Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 280891961275224919; Sun, 30 May 2010 06:08:39 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 30 May 2010 06:08:39 -0700 Message-ID: <4C026353.9030900@oracle.com> Date: Sun, 30 May 2010 06:08:35 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Zach Shelby References: <4BED6B9B.1060305@gridmerge.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090204.4C0263A6.0179:SCFMA922111,ss=1,fgs=0 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Comments on draft-ietf-6lowpan-nd-09 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sun, 30 May 2010 13:10:18 -0000 On 05/29/10 06:07 AM, Zach Shelby wrote: > Hi Robert, > > Thanks for the comments, below you'll find merged comments from the authors. On the nit and grammar related comments I will check those though while doing editing on nd-10 so don't be bothered that I skip them below. We have started creating tickets on changes in progress for nd-10. > > On May 14, 2010, at 6:26 PM, Robert Cragie wrote: > >> page 7: >> >> "EUI-64s are globally unique" - What about the case of spoofed/cloned EUI-64s? What would be the effect using this ND? Would it be significant? My guess is probably not but it might be worth making this clear > > We decided it might take a whole bunch of text to discuss all the issues that might happen with duplicate EUI-64s. For this spec we simply assume that EUI-64s are unique thus we don't try to detect duplicates. Just to clarifiy, this stance isn't just because we are lazy. I believe that detecting cloned/spoofed hosts in a 6lowpan environment is impossible. We assume that the clone is identical to the original host. Thus not only is the EUI-64 identical, but any other factory or configuration information is assumed to be identical. Suppose a simple topology with a single 6LBR, and the original and cloned hosts attach to this 6LBR. 1. How can the 6LBR tell the difference between a packet from the original and the clone? It can't, because they look the same and they arrive on the same interface on the 6LBR. For instance, if it receives a packet from the original with a high signal strength, and a millisecond later receives a low strength packet from the clone, that wouldn't indicate they there are two different hosts since the change in signal strength could happen with a single host and changing radio conditions. 2. Can the 6LBR do some challenge-response against the host(s) to see whether there is one host or two? That doesn't seem possible since the 6LBR can choose to target a transmission to only one of them (they are both within radio range and use the same MAC address). Thus any challenge would be heard by both of the hosts, and in many cases the clone might hear the response from the original host (and vice versa). Note that there other types of networks can detect duplicates. For example, if a cell phone is in Chicago and San Francisco at the same time one can assume that one of them is a clone. Or if the same source MAC address appears on different wired Ethernet switch ports at the same time, then it is probably a duplicate (or could be a single host which has two NICs, or that disconnected and the reconnected to the switch). In this case, the Ethernet switch can target some form of challenge by selectively sending out each of the ports, to be able to tell whether it is a move, a dual-attached single host, or a case of two hosts. If the link-layer creates some form of session keys as part of some association protocol, then I suspect one can also tell the there is a clone. But I don't know if anybody has studied the security of such approach. In any case, we assume none of those capabilities for 6lowpans. Erik From erik.nordmark@oracle.com Sun May 30 06:14:47 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13023A68A5 for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 06:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.911 X-Spam-Level: X-Spam-Status: No, score=-4.911 tagged_above=-999 required=5 tests=[AWL=1.688, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9S9TfrqwMCJ for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 06:14:25 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 9871C3A68A4 for <6lowpan@ietf.org>; Sun, 30 May 2010 06:14:17 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4UDE4ps011152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 May 2010 13:14:05 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4UD1Gxp002654; Sun, 30 May 2010 13:14:03 GMT Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 308933601275225229; Sun, 30 May 2010 06:13:49 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 30 May 2010 06:13:49 -0700 Message-ID: <4C02648A.5060800@oracle.com> Date: Sun, 30 May 2010 06:13:46 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Tetsuya Murakami References: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> In-Reply-To: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090204.4C02649D.01A0:SCFMA922111,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] SLLA option in NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sun, 30 May 2010 13:14:47 -0000 On 05/26/10 03:21 PM, Tetsuya Murakami wrote: > Hi All, > > According to the current 6lowpan-nd draft, I have one question. > > The draft mentioned NS must include SLLA option in order to inform > the link-layer address of the host. However when the router receives > RS message from the host, the router responds RA to the host. At that > time, the router needs to know the link-layer address of the host in > order to send out RA to the host. So, I think SLLA option of the host > must be included in RS instead of NS. We should make it clear that the SLLA is required in the RS. FWIW the ability to omit them in RFC4861 is for the case of sending a RS before DAD has completed, in which case RFC4861 allows an unspecified source address in the RS. We don't need that for 6lowpan. But we still need SLLA in the NS, since it is the SLLA plus the ARO that are used to form the registration with the router. > According to the current ND draft, after receiving RS message, the > router sends NS message in order to solve the link layer address of > the host by using solicited node multicast address. In order to > eliminate the multicast packet as much as possible, I recommend to > include SLLA option in RS instead of NS. I don't think there is anything in 6lowpan-nd-09 that says that the router should multicast a NS in this case. (RFC 4861 implementations might do that, or might instead multicast the RA to all-nodes.) Do you have a pointer to specific text in 6lowpan-nd-09 that says this, or that isn't sufficiently clear on never sending multicast NS? Erik From trac@tools.ietf.org Sun May 30 13:05:54 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 478823A682D for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 13:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.65 X-Spam-Level: X-Spam-Status: No, score=-100.65 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rquhmaOlAo3v for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 13:05:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 828283A6824 for <6lowpan@ietf.org>; Sun, 30 May 2010 13:05:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OIolR-0001VX-U6; Sun, 30 May 2010 13:05:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 30 May 2010 20:05:41 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/66#comment:1 Message-ID: <069.630ec8d9f53758d921218aa150f2384f@tools.ietf.org> References: <060.a0a51b549dd37daab824974892493632@tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <060.a0a51b549dd37daab824974892493632@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #66: Clarification of Section 8.2 (was: Clarification of Section 8.2 assumptions) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 20:05:54 -0000 #66: Clarification of Section 8.2 --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Comment(by zach@…): Some further clarifications to the Section 8.2 text have been identified by Erik: - The synchronous check against the 6LBR only needs to happen on the first ARO from a host. - The 6LR(s) need to maintain the DAD table in the 6LBRs, for instance by tracking how much is left of the lifetime they registered with the 6LBRs, and transmit multihop DAD messages appropriately. - I see some more care is needed in the specification around multihop DAD. In the case of multihop DAD I don't think the 6LR should create a Neighbor Cache entry until DAD has been verified. A possible way to handle not forgetting the SLLA (to be able to respond as you point out) would be to create a NCE but mark it as "unverified". Then an unverified NCE can be be used to send the response to the host, and if the response was "ok" then the unverified NCE would become a normal NCE, otherwise it would be deleted. -- Ticket URL: 6lowpan From trac@tools.ietf.org Sun May 30 13:08:30 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0913A6917 for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 13:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.914 X-Spam-Level: X-Spam-Status: No, score=-101.914 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2c6cwQY3ZKL for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 13:08:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5B8413A6824 for <6lowpan@ietf.org>; Sun, 30 May 2010 13:08:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OIonx-0001rM-QM; Sun, 30 May 2010 13:08:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 30 May 2010 20:08:17 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/68#comment:2 Message-ID: <069.613820739e1a3631037775826397c2bb@tools.ietf.org> References: <060.fe2bdc40f04a8c15333042ebfb94ba7c@tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <060.fe2bdc40f04a8c15333042ebfb94ba7c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #68: SLLA Option in RS and NS messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 20:08:30 -0000 #68: SLLA Option in RS and NS messages --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Comment(by zach@…): Also clarify what is in the unicast NS message: IPv6 source - the address the host wishes to register[[BR]] IPv6 destination - the unicast address of the router. Normally this will be a link-local address, since the RAs are send with a link-local source thus the default router list on the host ends up with link-local addresses for the router(s).[[BR]] NS target address - same as the IPv6 destination address. -- Ticket URL: 6lowpan From zach@sensinode.com Sun May 30 13:35:45 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEAE63A68CF for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 13:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzLLne0288WP for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 13:35:38 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id ADD703A682A for <6lowpan@ietf.org>; Sun, 30 May 2010 13:35:37 -0700 (PDT) Received: from [10.24.3.241] ([62.237.32.210]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4UKZKYE000308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Sun, 30 May 2010 23:35:21 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 30 May 2010 23:35:23 +0300 Message-Id: To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [6lowpan] 6lowpan-nd: How to detect if short-address is safe to use? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sun, 30 May 2010 20:35:45 -0000 In addition to the current tickets for nd-09, an issue was brought up on = the ZigBee IP list that we should discuss. When using a 16-bit IEEE 802.15.4 address generated at random (or = manually) with the nd-09 address registration procedure, how can one = detect if the address was checked for duplicates locally or across the = LoWPAN? In order for a host to safely start using a short address = generated like this it must know that it is unique throughout the = LoWPAN. Then upon failure the host can either generate and try to = register a new address or fall back to using an EUI-64 derived address. The current draft simply returns either Success or Duplicate Address = codes. The Success code doesn't tell a host if Section 8.2 (or some = other technique) has been used to perform DAD by the 6LR. We think there = is a need to clarify this situation for addresses where a check for = LoWPAN uniqueness is required. DAD may not be performed for multiple = reasons, a 6LBR may not be reachable, Section 8.2 might not be supported = or it may just fail.=20 I see two possible solutions if we agree this is a problem: A. Include a "DAD Required" flag in the ARO message sent by the host. If = the 6LR is not able to perform DAD, then it returns an error code = something like "DAD Unavailable". This DAD Required flag also makes it = easier for the 6LR to determine if an address was assigned by DHCPv6 = already thus not requiring DAD. B. Include a new Success code so that there are two, allowing for a host = to determine the extent to which a duplicate check was made. - Success and address checked for local uniqueness (0) - Success and address checked for LoWPAN uniqueness (1) Thoughts? Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From pthubert@cisco.com Sun May 30 23:15:51 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51C73A69E7 for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 23:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=1.722, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DQC6blJbdvx for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 23:15:44 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 881C83A6982 for <6lowpan@ietf.org>; Sun, 30 May 2010 23:15:39 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEvwAkyrR7Hu/2dsb2JhbACeMnGmD5kOhRYE X-IronPort-AV: E=Sophos;i="4.53,331,1272844800"; d="scan'208";a="537572661" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 31 May 2010 06:15:28 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4V6FPrX025653; Mon, 31 May 2010 06:15:28 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 08:15:26 +0200 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, 31 May 2010 08:15:22 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02015AA3@XMB-AMS-107.cisco.com> In-Reply-To: <4C002DB3.4030202@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Roll] how does a node get an IP address Thread-Index: Acr+qDRglMtyQy+XSwuu8Jc4QjqFhAB2RF7g References: <7069.1272031181@marajade.sandelman.ca><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-107.cisco.com> <4BE7AE79.6070608@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D01D60BE5@XMB-AMS-107.cisco.com><005a01caf046$8366a680$8a33f3 80$@sturek@att.net><007e01caf16d$4b39aa00$e1acfe00$@com> <6D9687E95918C04A8B30A7D6DA805A3E0142A144@zensys17.zensys.local><6A2A459175DABE4BB11DE2026AA50A5D01DF4948@XMB-AMS-107.cisco.com> <4C002DB3.4030 202@orac le.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , <6lowpan@ietf.org> X-OriginalArrivalTime: 31 May 2010 06:15:26.0562 (UTC) FILETIME=[A9451420:01CB0088] Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 31 May 2010 06:15:52 -0000 Hi Erik > The purpose of NUD in 6lowpan-nd is primarily to be able to detect when > one of the host's default routers have disappeared. > Thus I don't see how NUD can not be mandatory; the registration is for the > reverse direction - traffic from the router to the host. 2 things: 1) I favor the use of NUD as defined in RFC 4861 whenever possible. My reason is that it enables longer registration lifetime and thus more quietness in the peaceful / sleeping areas. RPL chose to include something similar for its own needs. 2) Still, we can live without NUD exactly like MIPv6 lives without it. Yes, traffic will be lost. And end-to-end failures can be a trigger to reassert the registration from the end node standpoint when that happens. Bidirectional reachability is asserted in the following fashion: - Host to router:=20 As you point out, NUD from the node can be important to avoid traffic loss since it enables the node to select an alternate router. You'll note, though, that many of the issues we see in a LoWPAN are really transient (like a 500ms interference) and are dealt with retries at L2 followed by sending the packet to an alternate router upon retries exhaustion, without necessarily declaring the first router off, or loosing traffic. A node can stay in a mode like this till the next registration. Having a sequence counter echoed is a useful thing because some of these links exhibit huge latencies. - Router to host: NUD from the router may induce false positives if the node is sleeping. OTOH, it can be quite critical to clean routes up and avoid mislead traffic to reach an area of the network where the node is no more. If the router keeps receiving registrations, it means that recent registrations passed. So we do not assert connectivity at that exact moment but recent connectivity. This is what REACH tells you seconds later anyway. When the node fails to register to a given router it will try another one and get its traffic through that one while the first one exhausts its registration lifetime and cleans up. This is why it is so important to enable seamless mobility in the subnet (MIPv6 would reject the analog move).=20 So not having NUD as defined in RFC 4861 may makes us loose some degree of immediateness, and some packets. This can be compensated by L2 and L4/5 triggers. An L2 trigger informs the L3 that the retries are exhausted and passes the packet back for alternate default routing. An L4/5 trigger informs that packets are lost and that connectivity to the default router(s) should be reasserted. Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Erik Nordmark > Sent: Friday, May 28, 2010 10:55 PM > To: 6lowpan@ietf.org > Subject: Re: [6lowpan] [Roll] how does a node get an IP address >=20 > On 05/12/10 04:31 AM, Pascal Thubert (pthubert) wrote: > > Hi Anders; > > > > The current ND draft has a white board, though it calls it a neighbor > > cache. Sometimes, renaming things is good. In this instance, I do not > > know. Clearly, standard neighbor cache entries must not be confused > > with the ones gleaned for the registration process, because only the > > latter can be fed into the backbone mechanism, be it route over or mesh > under. >=20 > I clarification might be in order. >=20 > In 6lowpan-nd-09, the only way a neighbor cache entry is created is from the > registration process. Thus there isn't any "gleaning" and any risk of conflicts. >=20 > > The White Board conceptually differs from the traditional Neighbor > > Cache: > > > > - The WB is a table as opposed to a cache. A neighbor cache entry can > > stay STALE for a very long time after the node is gone. A neighbor > > cache entry can be flushed to make room anytime. So a neighbor cache > > entry does not represent the node accurately enough to be > > redistributed in a routing protocol or proxied over a backbone. >=20 > That is true in RFC 4861, but section 6 in 6lowpan-nd-09 tries to make it clear > that the entries stay around until they time out. Is there something we > should make more clear in that section? >=20 > > - It is fed proactively using a registration as opposed to reactively > > to traffic. The registration and timely reregistration guarantees the > > presence of the node proactively. NUD is reactive, depends on traffic. > > It is nice to have but not mandatory as long as you have a registration. >=20 > The purpose of NUD in 6lowpan-nd is primarily to be able to detect when > one of the host's default routers have disappeared. > Thus I don't see how NUD can not be mandatory; the registration is for the > reverse direction - traffic from the router to the host. >=20 > Erik > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Sun May 30 23:19:00 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078E33A69EC for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 23:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.151 X-Spam-Level: X-Spam-Status: No, score=-8.151 tagged_above=-999 required=5 tests=[AWL=2.448, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxxMdPjTn813 for <6lowpan@core3.amsl.com>; Sun, 30 May 2010 23:18:59 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9DBE63A69E9 for <6lowpan@ietf.org>; Sun, 30 May 2010 23:18:58 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0HAHfxAkxAZnwN/2dsb2JhbACSLYwFcaYMmQ6FFgQ X-IronPort-AV: E=Sophos;i="4.53,331,1272844800"; d="scan'208";a="116431678" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 31 May 2010 06:18:46 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4V6Ik0D024729 for <6lowpan@ietf.org>; Mon, 31 May 2010 06:18:46 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 08:18:45 +0200 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, 31 May 2010 08:18:43 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02015AA4@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your message to 6lowpan awaits moderator approval Thread-Index: Acr5uL91iFldNFDfT6WzdrqQDqc03QG0DrSg From: "Pascal Thubert (pthubert)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 31 May 2010 06:18:45.0892 (UTC) FILETIME=[20146C40:01CB0089] Subject: [6lowpan] FW: Your message to 6lowpan awaits moderator approval X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 31 May 2010 06:19:00 -0000 Hi: I posted comments on the ND draft a week ago, but it seems that they did not show up on the list. Could someone do something? Pascal -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org]=20 Sent: Saturday, May 22, 2010 4:12 PM To: Pascal Thubert (pthubert) Subject: Your message to 6lowpan awaits moderator approval Your mail to '6lowpan' with the subject proposed changes for ND Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 83090 bytes with a limit of 40 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: =20 https://www.ietf.org/mailman/confirm/6lowpan/b68d7af2e957c58c2ef1026af67 a556ec28d59d6 From pthubert@cisco.com Sat May 22 07:11:59 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284FB3A6CF6 for <6lowpan@core3.amsl.com>; Sat, 22 May 2010 07:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7pZDI5tgN9r for <6lowpan@core3.amsl.com>; Sat, 22 May 2010 07:11:55 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id AF6513A6CF4 for <6lowpan@ietf.org>; Sat, 22 May 2010 07:11:53 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image003.gif, image004.png : 87, 6281 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQLAA6D90tAZnwN/2dsb2JhbABvT4FYmhBscaNpiHuQEgKEJ2oE X-IronPort-AV: E=Sophos;i="4.53,283,1272844800"; d="gif'147?png'147,150?scan'147,150,208,217,147,150";a="113786706" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 May 2010 14:11:46 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4MEBjYE018525; Sat, 22 May 2010 14:11:45 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 May 2010 16:11:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CAF9B8.B56B1190"; type="multipart/alternative" Date: Sat, 22 May 2010 16:09:20 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01F0C874@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: proposed changes for ND Thread-Index: Acr5uF8t/Y6EsuCSRZe5LlN4+XjyhA== From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , X-OriginalArrivalTime: 22 May 2010 14:11:45.0133 (UTC) FILETIME=[B5B531D0:01CAF9B8] X-Mailman-Approved-At: Sun, 30 May 2010 23:54:46 -0700 Cc: 6lowpan@ietf.org Subject: [6lowpan] proposed changes for ND X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 22 May 2010 14:11:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF9B8.B56B1190 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAF9B8.B56B1190" ------_=_NextPart_002_01CAF9B8.B56B1190 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgWmFjaDoNCg0KIA0KDQpQbGVhc2UgZmluZCBoZXJlYWZ0ZXIgc29tZSBwcm9wb3NlZCBlZGl0 b3JpYWwgY2hhbmdlcyB0byB0aGUgTkQgc3BlYyB0byBjb3ZlciB0aGUgaXNzdWVzIEkgcmVwb3J0 ZWQgc28gZmFyOg0KDQogDQoNCjEpICAgICAgTmFtaW5nIHRoZSByZWdpc3RyeS4gVGhlIE5EIHNw ZWMgaGFzIGEgcmVnaXN0cnkgaW4gZXZlcnkgcm91dGVyIHRoYXQgaXMgY2FsbGVkIE5EIGNhY2hl IGluIDA4LCBhbmQgdGhlbiBvbmUgbWFzdGVyIGluIHRoZSA2TEJSLCBjYWxsZWQgREFEIHRhYmxl Lg0KDQpUaGUgZm9ybWVyIG5hbWluZyBtaWdodCBiZSBjb25mdXNpbmcgaWYgdGhlIHJlZ2lzdHJ5 IGNvaGFiaXRzIHdpdGggYSBORCBjYWNoZSB0aGF0IG9iZXlzIFJGQzQ4NjEuIEFsc28sIHRoZSBj bG9zZSByZWxhdGlvbiBvZiB0aGUgMiB0YWJsZXMgaXMgbm90IG9idmlvdXMgcGVyIHRoZWlyIG5h bWVzDQoNCiANCg0Kw7AgIEkgc3VnZ2VzdCB3ZSBjYWxsIHRoZSByZWdpc3RyeSBhIHJlZ2lzdHJ5 LiBJbiBhbGwgNkxSIHJvdXRlcnMsIHRoYXQgd291bGQgYmUgdGhlIE5laWdoYm9ycyBSZWdpc3Ry eSBhbmQgdGhlIGFnZ3JlZ2F0aW9uIGluIHRoZSA2TEJSLCB0aGF0IHdvdWxkIGJlIHRoZSBNYXN0 ZXIgTmVpZ2hib3IgUmVnaXN0cnkuDQoNCk15IHRleHQgYmVsb3cgd2lsbCBhc3N1bWUgdGhhdCBu YW1pbmcNCg0KIA0KDQoyKSAgICAgIEFSTyBzZXF1ZW5jZSBjb3VudGVyDQoNClRoZSBzZXF1ZW5j ZSBjb3VudGVyIGlzIHVzZWZ1bCB0byBjb3JyZWxhdGUgYSByZXF1ZXN0IHdpdGggYSByZXNwb25z ZSwgaW4gcGFydGljdWxhciBiZXR3ZWVuIHRoZSA2TFIgYW5kIHRoZSA2TEJSLCB3aGljaCBjYW4g dGFrZSBzb21lIHRpbWUgYW5kIHJldHJpZXMgbWF5IGNyb3NzLiANCg0KV2UgYWxzIGtub3cgZnJv bSBlYXJsaWVyIHdvcmsgdGhhdCB0aGUgc2VxIG5iIHdpbGwgcGxheSBhIHJvbGUgdG8gaGFuZGxl IG1vYmlsaXR5IG92ZXIgdGhlIGJhY2tib25lLiBNeSBzdWdnZXN0aW9uIGlzIHRvIHBsYWNlIGl0 IGJhY2sgaW4gdGhlIHNwZWMuDQoNCiANCg0KIA0KDQozKSAgICAgIFJlbGF0aW9uIGJldHdlZW4g dGhlIE5laWdoYm9ycyBSZWdpc3RyeSBhbmQgb3RoZXIgdGFibGVzIGluIHRoZSByb3V0ZXINCg0K IA0KDQrDsCAgVGhlIE5SIGNhbiBiZSBpbmplY3RlZCBpbiB0aGUgUklCKHMpIHRvIGJlIHJlZGlz dHJpYnV0ZWQgaW4gcm91dGluZyBwcm90b2NvbHMuIChpbmplY3QpDQoNCsOwICBXaGVuIGFuIGVu dHJ5IGlzIGNyZWF0ZWQgaW4gdGhlIE5SLCBpdCBjYW4gYmUgZ2xlYW5lZCBpbiB0aGUgTmVpZ2hi b3IgQ2FjaGUuIChnbGVhbikNCg0Kw7AgIFdoZW4gYW4gZW50cnkgaXMgTlVEZWQsIGl0IGNhbiBi ZSBjbGVhbmVkIGZyb20gdGhlIE5laWdoYm9ycyBSZWdpc3RyeS4gKGNsZWFuKQ0KDQogDQoNCk5l dyBzZWN0aW9uICgzLjM/KQ0KDQogDQoNCkludGVyYWN0aW9uIGJldHdlZW4gdGhlIE5laWdoYm9y IGNhY2hlIGFuZCBvdGhlciBUYWJsZXMNCg0KIA0KDQogICBBIHR5cGljYWwgSVB2NiByb3V0ZXIg aGFuZGxlcyBvbmUgb3IgbW9yZSBSb3V0aW5nIFRhYmxlcyANCg0KICAoYWthIFJvdXRpbmcgSW5m b3JtYXRpb24gQmFzZXMpIGFuZCBvbmUgTmVpZ2hib3IgQ2FjaGUgcGVyIA0KDQppbnRlcmZhY2Uu IEF0IGEgc3RyaWN0IG1pbmltdW0sIGEgNkxSIG1pZ2h0IGhhdmUgZGVmYXVsdCANCg0Kcm91dGUg dmlhIHRoZSA2TEJSLCBhbmQgbm8gTmVpZ2hib3IgQ2FjaGUsIGlmIGl0IHJlbGllcyBvbmx5IA0K DQpvbiB0aGUgQVJPIHByb2Nlc3MgZGVzY3JpYmVkIGluIHRoaXMgc3BlYyB0byBkaXNjb3ZlciBp dHMNCg0KbmVpZ2hib3JpbmcgaG9zdC4gTW9yZSBjb21wbGV4IHNpdHVhdGlvbnMgbWF5IGFyaXNl IHdoZXJlIA0KDQp0aGUgTkQgY2FjaGUgYW5kIG9yIHRoZSBSSUJzIHBsYXkgdGhlaXIgZnVsbCBy b2xlLiBUaGlzIHNlY3Rpb24NCg0KZXhwbG9yZXMgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRo ZSBOUiBhbmQgdGhvc2UgdGFibGVzLg0KDQogDQoNCk1hc3RlciBOZWlnaGJvciBSZWdpc3RyeQ0K DQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgSW4gYSBzdWJuZXQgd2l0aCBtb3Jl IHRoYW4gb25lIHJvdXRlciwgaXQgaXMgZXhwZWN0ZWQgdGhhdCBvbmUNCg0KICAgUm91dGVyIGlz IGFuIDZMQlIgd2hlcmVhcyBhbGwgdGhlIG90aGVyIHJvdXRlcnMgYXJlIDZMUnMuIEFsbA0KDQog ICB0aGUgcm91dGVycyBhcmUgZXhwZWN0ZWQgdG8gbWFpbnRhaW4gYSBOZWlnaGJvciBSZWdpc3Ry eS4gQWxsIA0KDQogICB0aGUgZW50cmllcyBpbiB0aGUgTmVpZ2hib3IgUmVnaXN0cnkgTVVTVCBi ZSBpbmplY3RlZCBpbnRvIHRoZSANCg0KICAgTWFzdGVyIE5laWdoYm9yIFJlZ2lzdHJ5IGFzIHNw ZWNpZmllZCBpbiBzZWN0aW9uIDgsIHdoZXRoZXIgdGhleQ0KDQogICBhcmUgc3ViamVjdCB0byBE QUQgb3Igbm90LiBUaGlzIGVuYWJsZXMgdGhlIDZMQlIgdG8gcHJvdGVjdCB0aG9zZQ0KDQogICBh ZGRyZXNzZXMgYW5kIHRvIGV4cG9zZSB0aGVtIHRvIHRoZSBvdXRzaWRlLCBmb3IgZXhhbXBsZSBv dmVyIA0KDQogICBhIGJhY2toYXVsIG9yIGEgYmFja2JvbmUsIGluIGEgbWFubmVyIHRoYXQgaXMg b3V0c2lkZSB0aGUgc2NvcGUNCg0KICAgb2YgdGhpcyBkb2N1bWVudC4NCg0KIA0KDQogDQoNCiAg Ky0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rICAgICAgICAg ICAgICANCg0KICB8ICAgICAgICAgICAgIHwgICAgICAgIEluamVjdCAgICB8ICAgICAgICAgICAg IHwgICAgICAgICAgICAgICANCg0KICB8ICAgICAgICAgICAgIHwtLSsgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICANCg0KICB8ICAgICAgICAgICAgIHwgIHwgICAg ICA9PT0+ICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICANCg0KICB8ICAgICAgICAg ICAgIHwgIHwtLSsgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICANCg0K ICB8ICAgICAgICAgICAgIHwgIHwgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICANCg0KICB8ICAgICAgICAgICAgIHwgIHwgIHwgICAgICAgICAgICB8ICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICANCg0KICArLS0tLS0tLS0tLS0tLSsgIHwgIHwgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICANCg0KICAgICB8ICAgICAgICAgICAgIHwg IHwNCg0KICAgICArLS0tLS0tLS0tLS0tLSsgIHwNCg0KICAgICAgICB8ICAgICAgICAgICAgIHwN Cg0KICAgICAgICstLS0tLS0tLS0tLS0tKw0KDQogDQoNCiAgTmVpZ2hib3IgUmVnaXN0cnkgaW4g ICAgICAgICAgICAgIE1hc3RlciBOZWlnaGJvciBSZWdpc3RyeQ0KDQogIDZMUiBhbmQgNkxCUiAg ICAgICAgICAgICAgICAgICAgICBpbiA2TEJSDQoNCiANCg0KICBXaGVuIGFuIGVudHJ5IGhhcyB0 byBiZSByZW1vdmVkIGZyb20gdGhlIE5laWdoYm9yIFJlZ2lzdHJ5LCB0aGUgZW50cnkNCg0KICAg bXVzdCBmaXJzdCBiZSByZW1vdmVkIGZyb20gdGhlIE1hc3RlciBOZWlnaGJvciBSZWdpc3RyeS4g VGhpcyBpcw0KDQogICBjb25maXJtZWQgYnkgYW4gQVJPIG1lc3NhZ2Ugd2l0aCBhIHN1Y2Nlc3Nm dWwgc3RhdHVzIGFuZCBhIG51bGwgbGlmZXRpbWUNCg0KICAgb24gYSBzZXF1ZW5jZSB0aGF0IG1h dGNoZXMgdGhlIHJlcXVlc3QuIDwgbm90ZSB0byBhZGQgdGhlIHNlcXVlbmNlIG5iIGluIEFSTyA+ IA0KDQogDQoNClJJQnMNCg0KICAtLS0tLQ0KDQpCZWluZyBhIHJvdXRlciwgdGhlIDZMUi82TEJS IG1haW50YWluIG9uZSBvciBtb3JlIFJJQnMuIEluIHJvdXRlLW92ZXIsDQoNCnRoZSBSSUIgaXMg dXNlZCB0byByb3V0ZSBpbnNpZGUgdGhlIHN1Ym5ldCBhcyB3ZWxsIGFzIG91dHNpZGUuIA0KDQpX aXRoIFJQTCA8ZHJhZnQtcm9sbOKApj4gaXQgaXMgcG9zc2libGUgdGhhdCB0aGUgcm91dGVyIG1h aW50YWlucyBtdWx0aXBsZQ0KDQpSSUJzIChvciBWUkZzKSBpbiBvcmRlciB0byBzdXBwb3J0IG1v cmUgdGhhbiBvbmUgaW5zdGFuY2UuDQoNCiANCg0KQmVjYXVzZSBvZiB0aGUgd2F5IHRoZSBOZWln aGJvciBSZWdpc3RyeSBpcyBtYWludGFpbmVkIHByb2FjdGl2ZWx5LA0KDQppdCBpcyBwb3NzaWJs ZSB0byBpbmplY3QgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBOZWlnaGJvciBSZWdpc3RyeQ0KDQph cyBob3N0IHJvdXRlcyBpbiB0aGUgUklCKHMpLiBUaGUgaG9zdCByb3V0ZXMgYXJlIGluc3RhbGxl ZCBhcyBjb25uZWN0ZWQNCg0Kcm91dGVzLiBXaGVuIHRoZSBOZWlnaGJvciBSZWdpc3RyeSBlbnRy eSBpcyByZW1vdmVkLCB0aGUgcm91dGUgaW4gdGhlIFJJQg0KDQptdXN0IGJlIHJlbW92ZWQgYXMg d2VsbC4NCg0KIA0KDQogDQoNCiAgKy0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0rICAgICAgICAgICAgICANCg0KICB8ICAgICAgICAgICAgIHwgICAgICAgIElu amVjdCAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICANCg0KICB8ICAgICAgICAgICAg IHwtLSsgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICANCg0KICB8 ICAgICAgICAgICAgIHwgIHwgICAgICA8PT09ICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICANCg0KICB8ICAgICAgICAgICAgIHwgIHwtLSsgICAgICAgICAgICB8ICAgICAgICAgICAg IHwgICAgICAgICAgICAgICANCg0KICB8ICAgICAgICAgICAgIHwgIHwgIHwgICAgICAgICAgICB8 ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICANCg0KICB8ICAgICAgICAgICAgIHwgIHwgIHwg ICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICANCg0KICArLS0tLS0tLS0t LS0tLSsgIHwgIHwgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICANCg0K ICAgICB8ICAgICAgICAgICAgIHwgIHwNCg0KICAgICArLS0tLS0tLS0tLS0tLSsgIHwNCg0KICAg ICAgICB8ICAgICAgICAgICAgIHwNCg0KICAgICAgICArLS0tLS0tLS0tLS0tLSsNCg0KIA0KDQog IFJJQnMgaW4gYSAgICAgICAgICAgICAgICAgICAgICAgICAgTmVpZ2hib3IgUmVnaXN0cnkNCg0K ICA2TFIgb3IgNkxCUiAgICAgICAgICAgICAgICAgICAgICAgIHNhbWUgcm91dGVyDQoNCiANCg0K IA0KDQpUaGUgNkxCUiBtYXkgYWdncmVnYXRlIHRoZSBob3N0IHJvdXRlcyBhcyBvbmUgY29ubmVj dGVkIHJvdXRlIHRvIHRoZSANCg0Kd2hvbGUgcHJlZml4IG9uIGl0cyA2TG9XUEFOIGludGVyZmFj ZSB0aGF0IHNlcnZlcyB0aGUgc3VibmV0Lg0KDQogDQoNClJvdXRpbmcgcHJvdG9jb2xzIHN1Y2gg YXMgUlBMIG1heSB0aGVuIHJlZGlzdHJpYnV0ZSB0aGUgY29ubmVjdGVkIHJvdXRlDQoNCmZyb20g dGhlIFJJQihzKSB0aGF0IHRoZXkgc2VydmUgYW4gdGh1cyBpbmplY3QgdGhlIGhvc3Qgb3IgcHJl Zml4IHJvdXRlcw0KDQppbiB0aGVpciBvd24gcm91dGluZyBmYWJyaWMuDQoNCiANCg0KTkQgY2Fj aGUNCg0KLS0tLS0tLS0NCg0KIA0KDQpBIDZMUi82TEJSIG1heSBzdXBwb3J0IHRoaXMgc3BlY2lm aWNhdGlvbiBhbmQgTmVpZ2hib3IgRGlzY292ZXJ5IGFzIHNwZWNpZmllZA0KDQppbiBSRkMgNDg2 MSBvbiBhIHNhbWUgaW50ZXJmYWNlLiBJbiB0aGF0IGNhc2UsIE5EIGNhY2hlIGVudHJpZXMgY2Fu IGJlIGdsZWFuZWQNCg0KZnJvbSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MsIGFuZCBlbnRyaWVz IHRoYXQgYXJlIHN1YmplY3QgdG8gTlVEIG1pZ2h0IGJlIA0KDQpjbGVhbmVkIGZyb20gdGhlIE5l aWdoYm9yIFJlZ2lzdHJ5Lg0KDQogDQoNCiAgKy0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICANCg0KICB8ICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICANCg0KICB8ICAgICAg ICAgICAgIHwtLSsgICAgIEdsZWFuICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAN Cg0KICB8ICAgICAgICAgICAgIHwgIHwgICAgICA8PT09ICAgICB8ICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICANCg0KICB8ICAgICAgICAgICAgIHwgIHwtLSsgICAgICAgICAgICB8ICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICANCg0KICB8ICAgICAgICAgICAgIHwgIHwgIHwgIENsZWFu ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIA0KDQogIHwgICAgICAgICAgICAgfCAg fCAgfCAgID09PT4gICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIA0KDQogICstLS0t LS0tLS0tLS0tKyAgfCAgfCAgICAgICAgICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAg IA0KDQogICAgIHwgICAgICAgICAgICAgfCAgfA0KDQogICAgICstLS0tLS0tLS0tLS0tKyAgfA0K DQogICAgICAgIHwgICAgICAgICAgICAgfA0KDQogICAgICAgICstLS0tLS0tLS0tLS0tKw0KDQog DQoNCiAgTmVpZ2hib3IgQ2FjaGUgcHJlDQoNCiAgSW50ZXJmYWNlIGluIGEgICAgICAgICAgICAg ICAgICAgICAgTmVpZ2hib3IgUmVnaXN0cnkNCg0KICA2TFIgYW5kIDZMQlIgICAgICAgICAgICAg ICAgICAgICAgICBzYW1lIHJvdXRlcg0KDQogDQoNCkluIGEgbmV0d29yayB3aGVyZSBub2RlIG1p Z2h0IGJlIHNsZWVwaW5nIGZvciBhIGxvbmcgdGltZSwgTlVEIG1pZ2h0IHdyb25nbHkNCg0KZGV0 ZXJtaW5lIHRoYXQgYSBub2RlIGlzIHVucmVhY2hhYmxlIHNvIGl0ICBtdXN0IGJlIHBvc3NpYmxl IHRvIHR1cm4gb2ZmDQoNCiAgIHRoZSBjbGVhbmluZyBvcGVyYXRpb24uIEluIG1vc3QgY2FzZXMs IHRob3VnaCwgaXQgaXMgZXhwZWN0ZWQgdGhhdCBzbGVlcGluZyBub2Rlcw0KDQogICBlbmQgdXAg cmVjZWl2aW5nIHRoZWlyIHRyYWZmaWMsIGFuZCBzaG91bGQgc3RheSBhd2FrZSBsb25nIGVub3Vn aCB0byBhbnN3ZXIgdGhlDQoNCiAgIHBvbGxpbmcuIA0KDQogDQoNCiANCg0KIA0KDQogDQoNCiAN Cg0KIA0KDQogDQoNCiANCg0KIA0KDQogDQoNCjQpICAgICAgVG9wb2xvZ3kgc3VwcG9ydGVkIA0K DQogDQoNClRoZSBkb2MgY291bGQgYmUgbW9yZSBjbGVhciBhYm91dCB3aGF04oCZcyBpbiB3aGF0 4oCZcyBvdXQuIEluIHBhcnRpY3VsYXIsIGl0IGFwcGVhcnMgdG8gbWUgdGhhdCB3ZSBiZXR0ZXIg c2F5IHRoYXQgd2Ugc3VwcG9ydCBvbmx5IG9uZSBMQlIgYW5kIHRoYXQgdGhlIHN1cHBvcnQgdG8g c2NhbGUgdG8gbW9yZSB0aGFuIG9uZSBMQlIsIGZvciBpbnN0YW5jZSB1c2luZyBhIGJhY2tib25l LCBpcyBvdXQgb2Ygc2NvcGUuIFdlIGNhbiBhbHNvIHNheSB0aGF0IHRoZSBMQlIga25vd3MgYWxs IHRoZSBhZGRyZXNzZXMgaW4gdGhlIHN1Ym5ldCB0aGF0IGl0IGNvdmVycywgYW5kIHRoYXQgaXQg Y2FuIGVpdGhlciByZXByZXNlbnQgdGhlbSBvdmVyIGEgYmFja2hhdWwgb3IgYSBiYWNrYm9uZSwg b3IgYWdncmVnYXRlIHRoZW0uDQoNCiANCg0K4oCcDQoNCiAgIEluIGEgbWVzaC11bmRlciBjb25m aWd1cmF0aW9uIGEgNkxCUiBpcyBhY3RpbmcgYXMgdGhlIElQdjYgcm91dGVyDQoNCiAgIHdoZXJl IGFsbCB0aGUgaG9zdHMgaW4gdGhlIExvV1BBTiBhcmUgb24gdGhlIHNhbWUgbGluaywgdGh1cyB0 aGV5IGFyZQ0KDQogICBvbmx5IG9uZSBJUCBob3AgYXdheS4gIE5vIDZMb1dQQU4gUm91dGVycyBl eGlzdCBpbiB0aGlzIHRvcG9sb2d5IGFzDQoNCiAgIGZvcndhcmRpbmcgaXMgaGFuZGxlZCBieSBh IGxpbmstbGF5ZXIgbWVzaCByb3V0aW5nIHByb3RvY29sLg0KDQrigJwNCg0KPT4NCg0K4oCcDQoN CiAgIE1lc2gtdW5kZXIgY29uZmlndXJhdGlvbnMgdmFyeSBhIGxvdCwgZG8gbm90IGd1YXJhbnRl ZSBhbnkgdG8gYW55IA0KDQogICBkaXJlY3QgY29ubmVjdGl2aXR5LCBhbmQgbWF5IGdyb3cgdmVy eSBsYXJnZS4gSXQgaXMgZXhwZWN0ZWQgdGhhdCANCg0KICAgYSBob3N0IGlzIG9uZSBtZXNoIHVu ZGVyIGhvcCBhd2F5IGZyb20gYXQgbGVhc3Qgb25lIDZMUiwgYW5kIHRoYXQNCg0KICAgYWxsIHRo ZSA2TFJzIGhhdmUgYSBtZXNoIHVuZGVyIGNvbm5lY3Rpb24gdG8gdGhlIDZMQlJzLiBDb25maWd1 cmF0aW9ucw0KDQogICB3aXRoIG1vcmUgdGhhbiBvbmUgNkxCUiBhcmUgbm90IHN1cHBvcnRlZCBi eSB0aGlzIHNwZWNpZmljYXRpb24uDQoNCuKAnA0KDQogDQoNCuKAnA0KDQogICBvICBBIG5ldyBv cHRpb25hbCBtZWNoYW5pc20gdG8gcGVyZm9ybSBEdXBsaWNhdGUgQWRkcmVzcyBEZXRlY3Rpb24N CiAgICAgIGFjcm9zcyBhIHJvdXRlLW92ZXIgNkxvV1BBTiByZXVzaW5nIHRoZSBhYm92ZSBBZGRy ZXNzIFJlZ2lzdHJhdGlvbg0KICAgICAgb3B0aW9uLg0KDQrigJwNCg0KPT4NCg0K4oCcDQoNCiAg IG8gIEEgbmV3IG9wdGlvbmFsIG1lY2hhbmlzbSB0byBwZXJmb3JtIER1cGxpY2F0ZSBBZGRyZXNz IERldGVjdGlvbg0KICAgICAgYWNyb3NzIGEgbGFyZ2UgNkxvV1BBTiB3aXRoIG11bHRpcGxlIDZM UnMgcmV1c2luZyB0aGUgYWJvdmUgQWRkcmVzcyANCiAgICAgIFJlZ2lzdHJhdGlvbiBvcHRpb24u DQoNCuKAnA0KDQogDQoNCiANCg0K4oCcDQoNCiAgIE9wdGlvbmFsbHkgdGhlIFJvdXRlciBBZHZl cnRpc2VtZW50IG1lc3NhZ2VzIGNhbiBiZSB1c2VkIHRvDQogICBkaXNzZW1pbmF0ZSBwcmVmaXhl cyB0byBhbGwgdGhlIDZMUnMgaW4gYSByb3V0ZS1vdmVyIHRvcG9sb2d5LiAgVGhpcw0KICAgaXMg b3B0aW9uYWwgYmVjYXVzZSB0aGVyZSBhcmUgbGlrZWx5IHRvIGJlIG90aGVyIG1lY2hhbmlzbXMg Zm9yIHN1Y2gNCiAgIGluZm9ybWF0aW9uIGRpc3RyaWJ1dGlvbi4NCg0K4oCcDQoNCj0+DQoNCuKA nA0KDQogICBPcHRpb25hbGx5IHRoZSBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBtZXNzYWdlcyBjYW4g YmUgdXNlZCB0bw0KICAgZGlzc2VtaW5hdGUgcHJlZml4ZXMgdG8gYWxsIHRoZSA2TFJzLiBUaGlz DQogICBpcyBvcHRpb25hbCBiZWNhdXNlIHRoZXJlIGFyZSBsaWtlbHkgdG8gYmUgb3RoZXIgbWVj aGFuaXNtcyBmb3Igc3VjaA0KICAgaW5mb3JtYXRpb24gZGlzdHJpYnV0aW9uLg0KDQrigJwNCg0K IA0KDQogDQoNCuKAnA0KDQogICBXaGVuIGEgNkxSIHRoYXQgaW1wbGVtZW50cyB0aGUgb3B0aW9u YWwgbXVsdGlob3AgREFEIHJlY2VpdmVzIGFuIE5TDQogICBmcm9tIGEgaG9zdCAodGhlIEFSTyBo YXMgTGVuZ3RoID0gMikgYW5kIHRoZSA2TFIgZG9lcyBub3QgYWxyZWFkeQ0KICAgaGF2ZSBhIE5l aWdoYm9yIENhY2hlIGVudHJ5IGZvciB0aGUgaG9zdCdzIElQdjYgYWRkcmVzcywgdGhlbiB0aGUg NkxSDQogICBmb3JtcyBhbmQgc2VuZHMgYW4gTlMgdG8gYXQgbGVhc3Qgb25lIDZMQlIuIA0KIA0K DQrigJwNCg0KPT4NCg0K4oCcDQoNCiAgIFdoZW4gYSA2TFIgdGhhdCBpbXBsZW1lbnRzIHRoZSBv cHRpb25hbCBtdWx0aWhvcCBEQUQgcmVjZWl2ZXMgYW4gTlMNCiAgIGZyb20gYSBob3N0ICh0aGUg QVJPIGhhcyBMZW5ndGggPSAyKSBhbmQgdGhlIDZMUiBkb2VzIG5vdCBhbHJlYWR5DQogICBoYXZl IGEgTmVpZ2hib3IgQ2FjaGUgZW50cnkgZm9yIHRoZSBob3N0J3MgSVB2NiBhZGRyZXNzLCB0aGVu IHRoZSA2TFINCiAgIGZvcm1zIGFuZCBzZW5kcyBhbiBOUyB0byB0aGUgNkxCUi4gQSBjb25maWd1 cmF0aW9uIHdpdGggbXVsdGlwbGUgNkxCUnMNCiAgIGlzIG5vdCBzdXBwb3J0ZWQgYnkgdGhpcyBz cGVjaWZpY2F0aW9uLiBJdCBpcyBleHBlY3RlZCB0aGF0IHRoZSA2TEJScyANCiAgIHdvdWxkIHN5 bmNocm9uaXplIHByb2FjdGl2ZWx5IG9yIHJlYWN0aXZlbHkgdGhlaXIgTWFzdGVyIE5laWdoYm9y IA0KICAgcmVnaXN0cmllcyBiZXR3ZWVuIHRoZW1zZWx2ZXMgd2l0aCBub3QgYWRkaXRpb25hbCBh Y3Rpb24gYnkgdGhlIDZMUi4NCiANCg0K4oCcDQoNCiANCg0KIA0KDQogDQoNCjUpICAgICAgbWVy Z2luZyB0aGUgZGlzc2VtaW5hdGlvbiBwcm9jZXNzIHdpdGggdGhlIHJlZ2lzdHJhdGlvbiBwcm9j ZXNzIG1heSBzbG93IGRvd24gdGhlIGFkb3B0aW9uIG9mIHRoZSBsYXR0ZXIuIA0KDQpBbHNvLCBz b21lIGNvbmZpZ3VyYXRpb25zIHVzaW5nIGFuIGFsdGVybmF0ZSBkaXNzZW1pbmF0aW9uIHByb2Nl c3MgbWlnaHQgbm90IHJlcXVpcmUgdGhhdCBmZWF0dXJlIGZyb20gTkQuIA0KDQpTbyBJ4oCZZCBz dWdnZXN0IHdlIG1ha2UgaXQgYSBzZXBhcmF0ZSBzcGVjIGFuZCB3ZSBmb2N1cyBkZWVwbHkgb24g dGhlIHJlZ2lzdHJhdGlvbiBmb3IgdGhlIHRpbWUgYmVpbmcuDQoNCiANCg0KIA0KDQpDaGVlcnMs DQoNCiANCg0KIA0KDQoJDQpQYXNjYWwgVGh1YmVydA0KRW5naW5lZXIuc29mdHdhcmUgRW5naW5l ZXJpbmcNClByb2R1Y3QgRGV2ZWxvcG1lbnQNCnB0aHViZXJ0QGNpc2NvLmNvbSA8bWFpbHRvOnB0 aHViZXJ0QGNpc2NvLmNvbT4gDQpQaG9uZTogKzMzIDQgOTcyMyAyNjM0DQpNb2JpbGU6ICszMyA2 IDE5OTggMjk4NQ0KDQoNCg0KQ2lzY28gU3lzdGVtcyBGcmFuY2UNClZpbGxhZ2UgZCdFbnRyZXBy aXNlcyBHcmVlbiBTaWRlDQo0MDAgQXZlbnVlIGRlIFJvdW1hbmlsbGUgDQpCYXRpbWVudCBUIDMg DQowNjQxMCANCkJJT1QgLSBTT1BISUEgQU5USVBPTElTDQpGcmFuY2UNCkNpc2NvLmNvbSA8aHR0 cDovL3d3dy5jaXNjby5jb20vZ2xvYmFsL0ZSLz4gDQoNCiAgDQoNCiANCg0KIFRoaW5rIGJlZm9y ZSB5b3UgcHJpbnQuDQoNCkNpc2NvIFN5c3RlbXMgRnJhbmNlLCBTb2Npw6l0w6kgw6AgcmVzcG9u c2FiaWl0w6kgbGltaXTDqWUsIFJ1ZSBDYW1pbGxlIERlc21vdWxpbnMg4oCTIEltbSBBdGxhbnRp cyBaYWMgRm9ydW0gU2VpbmUgSWxvdCA3IDkyMTMwIElzc3kgbGVzIE1vdWxpbmVhdXgsIEF1IGNh cGl0YWwgZGUgOTEuNDcwIOKCrCwgMzQ5IDE2NiA1NjEgUkNTIE5hbnRlcnJlLCBEaXJlY3RldXIg ZGUgbGEgcHVibGljYXRpb246IEplYW4tTHVjIE1pY2hlbCBHaXZvbmUsIEZvciBjb3Jwb3JhdGUg bGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQpodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQv ZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwgPGh0dHA6Ly93d3cuY2lzY28uY29t L3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbD4gDQoNCiANCg0K IA0KDQo= ------_=_NextPart_002_01CAF9B8.B56B1190 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAw IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOp Zm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1z b0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0 b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVz IENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBk ZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBy Zm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBI VE1MIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6NTQwNjMxNjI4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotNzA3MDkxNjE2IDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3 Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0 OjE4LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTQuMHB0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6OTAuMHB0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEy Ni4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE2Mi4wcHQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDoxOTguMHB0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIz NC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI3MC4wcHQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDozMDYuMHB0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo2NTgzMDkzNjA7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjUwMjk1NDc1NiA2 NTQxOTA5MzggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg7A7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1s ZWZ0OjU0LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 OTAuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTI2LjBwdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6MTYyLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE5OC4wcHQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMzQuMHB0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDoyNzAuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzA2LjBwdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjM0Mi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1 ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFs PkhpIFphY2g6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5QbGVhc2UgZmluZCBoZXJlYWZ0ZXIgc29tZSBwcm9w b3NlZCBlZGl0b3JpYWwgY2hhbmdlcyB0byB0aGUgTkQgc3BlYyB0byBjb3ZlciB0aGUgaXNzdWVz IEkgcmVwb3J0ZWQgc28gZmFyOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4t bGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+MSk8c3Bh biBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPk5hbWluZyB0aGUgcmVnaXN0cnku IFRoZSBORCBzcGVjIGhhcyBhIHJlZ2lzdHJ5IGluIGV2ZXJ5IHJvdXRlciB0aGF0IGlzIGNhbGxl ZCBORCBjYWNoZSBpbiAwOCwgYW5kIHRoZW4gb25lIG1hc3RlciBpbiB0aGUgNkxCUiwgY2FsbGVk IERBRCB0YWJsZS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxl PSdtYXJnaW4tbGVmdDoxOC4wcHQnPlRoZSBmb3JtZXIgbmFtaW5nIG1pZ2h0IGJlIGNvbmZ1c2lu ZyBpZiB0aGUgcmVnaXN0cnkgY29oYWJpdHMgd2l0aCBhIE5EIGNhY2hlIHRoYXQgb2JleXMgUkZD NDg2MS4gQWxzbywgdGhlIGNsb3NlIHJlbGF0aW9uIG9mIHRoZSAyIHRhYmxlcyBpcyBub3Qgb2J2 aW91cyBwZXIgdGhlaXIgbmFtZXM8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdy YXBoIHN0eWxlPSdtYXJnaW4tbGVmdDoxOC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNs YXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseTpXaW5nZGluZ3MnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsOwPHNwYW4gc3R5 bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+SSBzdWdnZXN0IHdlIGNhbGwgdGhlIHJlZ2lzdHJ5IGEgcmVnaXN0cnku IEluIGFsbCA2TFIgcm91dGVycywgdGhhdCB3b3VsZCBiZSB0aGUgTmVpZ2hib3JzIFJlZ2lzdHJ5 IGFuZCB0aGUgYWdncmVnYXRpb24gaW4gdGhlIDZMQlIsIHRoYXQgd291bGQgYmUgdGhlIE1hc3Rl ciBOZWlnaGJvciBSZWdpc3RyeS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdy YXBoPk15IHRleHQgYmVsb3cgd2lsbCBhc3N1bWUgdGhhdCBuYW1pbmc8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1z b0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4yKTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBO ZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+QVJPIHNlcXVlbmNlIGNvdW50ZXI8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29M aXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDoxOC4wcHQnPiBUaGUgc2VxdWVuY2UgY291 bnRlciBpcyB1c2VmdWwgdG8gY29ycmVsYXRlIGEgcmVxdWVzdCB3aXRoIGEgcmVzcG9uc2UsIGlu IHBhcnRpY3VsYXIgYmV0d2VlbiB0aGUgNkxSIGFuZCB0aGUgNkxCUiwgd2hpY2ggY2FuIHRha2Ug c29tZSB0aW1lIGFuZCByZXRyaWVzIG1heSBjcm9zcy4gPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTguMHB0Jz5XZSBhbHMga25vdyBm cm9tIGVhcmxpZXIgd29yayB0aGF0IHRoZSBzZXEgbmIgd2lsbCBwbGF5IGEgcm9sZSB0byBoYW5k bGUgbW9iaWxpdHkgb3ZlciB0aGUgYmFja2JvbmUuIE15IHN1Z2dlc3Rpb24gaXMgdG8gcGxhY2Ug aXQgYmFjayBpbiB0aGUgc3BlYy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4zKTxzcGFuIHN0eWxlPSdmb250Ojcu MHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+UmVsYXRpb24gYmV0d2VlbiB0aGUgTmVpZ2hib3JzIFJlZ2lz dHJ5IGFuZCBvdGhlciB0YWJsZXMgaW4gdGhlIHJvdXRlcjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjE4LjBwdCc+PG86cD4mbmJzcDs8 L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OldpbmdkaW5ncyc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9y ZSc+w7A8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7IDwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgTlIgY2FuIGJlIGluamVjdGVkIGluIHRo ZSBSSUIocykgdG8gYmUgcmVkaXN0cmlidXRlZCBpbiByb3V0aW5nIHByb3RvY29scy4gKGluamVj dCk8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6V2luZ2RpbmdzJz48c3BhbiBzdHlsZT0nbXNvLWxp c3Q6SWdub3JlJz7DsDxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4m bmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPldoZW4gYW4gZW50cnkgaXMgY3Jl YXRlZCBpbiB0aGUgTlIsIGl0IGNhbiBiZSBnbGVhbmVkIGluIHRoZSBOZWlnaGJvciBDYWNoZS4g KGdsZWFuKTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3Rl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpXaW5nZGluZ3MnPjxzcGFuIHN0eWxlPSdt c28tbGlzdDpJZ25vcmUnPsOwPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21h biInPiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+V2hlbiBhbiBlbnRyeSBp cyBOVURlZCwgaXQgY2FuIGJlIGNsZWFuZWQgZnJvbSB0aGUgTmVpZ2hib3JzIFJlZ2lzdHJ5LiAo Y2xlYW4pPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48bzpwPiZuYnNw OzwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPk5ldyBzZWN0aW9uICgzLjM/KTxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PG86cD4mbmJzcDs8L286cD48 L3A+PGRpdiBzdHlsZT0nbXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpub25lO2Jv cmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMS4wcHQg MGNtO21hcmdpbi1sZWZ0OjM2LjBwdDttYXJnaW4tcmlnaHQ6MGNtJz48cCBjbGFzcz1Nc29MaXN0 UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDowY207Ym9yZGVyOm5vbmU7cGFkZGluZzowY20n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PkludGVyYWN0aW9uIGJldHdlZW4gdGhlIE5laWdoYm9yIGNhY2hlIGFuZCBvdGhlciBUYWJsZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48bzpw PiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoCBBIHR5cGljYWwgSVB2NiBy b3V0ZXIgaGFuZGxlcyBvbmUgb3IgbW9yZSBSb3V0aW5nIFRhYmxlcyA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqAoYWthIFJvdXRpbmcgSW5mb3JtYXRpb24gQmFz ZXMpIGFuZCBvbmUgTmVpZ2hib3IgQ2FjaGUgcGVyIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjE4LjBwdCc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+aW50ZXJmYWNlLiBBdCBh IHN0cmljdCBtaW5pbXVtLCBhIDZMUiBtaWdodCBoYXZlIGRlZmF1bHQgPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0Jz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5yb3V0 ZSB2aWEgdGhlIDZMQlIsIGFuZCBubyBOZWlnaGJvciBDYWNoZSwgaWYgaXQgcmVsaWVzIG9ubHkg PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRl bnQ6MTguMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz5vbiB0aGUgQVJPIHByb2Nlc3MgZGVzY3JpYmVkIGluIHRoaXMgc3BlYyB0byBk aXNjb3ZlciBpdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSd0ZXh0LWluZGVudDoxOC4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPm5laWdoYm9yaW5nIGhvc3QuIE1vcmUgY29tcGxleCBzaXR1 YXRpb25zIG1heSBhcmlzZSB3aGVyZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnRoZSBORCBjYWNoZSBhbmQgb3IgdGhl IFJJQnMgcGxheSB0aGVpciBmdWxsIHJvbGUuIFRoaXMgc2VjdGlvbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjE4LjBwdCc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ZXhwbG9y ZXMgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBOUiBhbmQgdGhvc2UgdGFibGVzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjE4 LjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0ndGV4dC1pbmRlbnQ6MTguMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz5NYXN0ZXIgTmVpZ2hib3IgUmVnaXN0cnk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqAgSW4gYSBzdWJu ZXQgd2l0aCBtb3JlIHRoYW4gb25lIHJvdXRlciwgaXQgaXMgZXhwZWN0ZWQgdGhhdCBvbmU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqAgUm91dGVyIGlzIGFuIDZM QlIgd2hlcmVhcyBhbGwgdGhlIG90aGVyIHJvdXRlcnMgYXJlIDZMUnMuIEFsbDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoCB0aGUgcm91dGVycyBhcmUgZXhwZWN0 ZWQgdG8gbWFpbnRhaW4gYSBOZWlnaGJvciBSZWdpc3RyeS4gQWxsIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoMKgdGhlIGVudHJpZXMgaW4gdGhlIE5laWdoYm9y IFJlZ2lzdHJ5IE1VU1QgYmUgaW5qZWN0ZWQgaW50byB0aGUgPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz7CoMKgwqBNYXN0ZXIgTmVpZ2hib3IgUmVnaXN0cnkgYXMgc3Bl Y2lmaWVkIGluIHNlY3Rpb24gOCwgd2hldGhlciB0aGV5PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz7CoMKgIGFyZSBzdWJqZWN0IHRvIERBRCBvciBub3QuIFRoaXMgZW5h YmxlcyB0aGUgNkxCUiB0byBwcm90ZWN0IHRob3NlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz7CoMKgIGFkZHJlc3NlcyBhbmQgdG8gZXhwb3NlIHRoZW0gdG8gdGhlIG91 dHNpZGUsIGZvciBleGFtcGxlIG92ZXIgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz7CoMKgwqBhIGJhY2toYXVsIG9yIGEgYmFja2JvbmUsIGluIGEgbWFubmVyIHRoYXQg aXMgb3V0c2lkZSB0aGUgc2NvcGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPsKgwqAgb2YgdGhpcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoCArLS0tLS0t LS0tLS0tLSvCoMKgwqDCoMKgwqAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCstLS0tLS0tLS0tLS0t K8KgwqDCoMKgwqDCoMKgwqDCoMKgIMKgwqDCoDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+wqDCoHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKg IEluamVjdMKgIMKgwqB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCDCoDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDC oHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfC0tK8KgwqDCoMKgwqDCoMKgwqAgwqDCoMKgwqDC oMKgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg wqA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqB8wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHzCoCB8wqDCoMKgwqDCoCA9PT0mZ3Q7wqAgwqDCoMKgfMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgwqA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqB8wqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIHzCoCB8LS0rwqDCoMKgwqDCoMKgwqAgwqDCoMKgwqB8wqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCDCoDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+wqDCoHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIHzCoCB8 wqDCoMKgwqDCoMKgwqAgwqDCoMKgwqB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCDCoDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+wqDCoHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIHzCoCB8wqDCoMKgwqDCoMKg wqAgwqDCoMKgwqB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCDCoDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoCst LS0tLS0tLS0tLS0tK8KgIHzCoCB8wqDCoMKgwqDCoMKgwqAgwqDCoMKgwqArLS0tLS0tLS0tLS0t LSvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgwqDCoDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+wqDCoMKgwqDCoHzCoMKgwqDCoMKgwqAgwqDCoMKgwqDCoMKgfMKgIHw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqDCoMKgICstLS0tLS0t LS0tLS0tK8KgIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqAg wqDCoMKgwqDCoHzCoMKgwqDCoMKgwqAgwqDCoMKgwqDCoMKgfDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+IMKgwqDCoMKgwqDCoMKgKy0tLS0tLS0tLS0tLS0rPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgIE5laWdoYm9yIFJlZ2lzdHJ5IGluIMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgTWFzdGVyIE5laWdoYm9yIFJlZ2lzdHJ5PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz7CoCA2TFIgYW5kIDZMQlLCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCDCoMKgaW4gNkxCUjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz4gwqDCoFdoZW4gYW4gZW50cnkgaGFzIHRvIGJlIHJlbW92ZWQgZnJvbSB0aGUgTmVp Z2hib3IgUmVnaXN0cnksIHRoZSBlbnRyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+wqDCoCBtdXN0IGZpcnN0IGJlIHJlbW92ZWQgZnJvbSB0aGUgTWFzdGVyIE5laWdo Ym9yIFJlZ2lzdHJ5LiBUaGlzIGlzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciJz7CoMKgIGNvbmZpcm1lZCBieSBhbiBBUk8gbWVzc2FnZSB3aXRoIGEgc3VjY2Vzc2Z1bCBz dGF0dXMgYW5kIGEgbnVsbCBsaWZldGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+wqDCoCBvbiBhIHNlcXVlbmNlIHRoYXQgbWF0Y2hlcyB0aGUgcmVxdWVzdC4gJmx0 OyBub3RlIHRvIGFkZCB0aGUgc2VxdWVuY2UgbmIgaW4gQVJPICZndDsgPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQnPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlJJQnM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgIC0tLS0tPG86cD48L286cD48L3NwYW4+ PC9wPjxkaXYgc3R5bGU9J21zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6bm9uZTti b3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gMGNtIDEuMHB0 IDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVy Om5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPkJlaW5nIGEgcm91dGVyLCB0aGUgNkxSLzZMQlIgbWFpbnRhaW4g b25lIG9yIG1vcmUgUklCcy4gSW4gcm91dGUtb3Zlciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFk ZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPnRoZSBSSUIgaXMgdXNlZCB0byByb3V0ZSBpbnNpZGUgdGhlIHN1Ym5ldCBhcyB3 ZWxsIGFzIG91dHNpZGUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J3RleHQtaW5kZW50OjE4LjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+V2l0aCBS UEwgJmx0O2RyYWZ0LXJvbGzigKYmZ3Q7IGl0IGlzIHBvc3NpYmxlIHRoYXQgdGhlIHJvdXRlciBt YWludGFpbnMgbXVsdGlwbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlJJQnMg KG9yIFZSRnMpIGluIG9yZGVyIHRvIHN1cHBvcnQgbW9yZSB0aGFuIG9uZSBpbnN0YW5jZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDox OC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjE4LjBwdDtib3JkZXI6bm9u ZTtwYWRkaW5nOjBjbSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+QmVjYXVzZSBvZiB0aGUgd2F5IHRoZSBOZWlnaGJvciBSZWdpc3RyeSBp cyBtYWludGFpbmVkIHByb2FjdGl2ZWx5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjE4LjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBj bSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+aXQgaXMgcG9zc2libGUgdG8gaW5qZWN0IHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgTmVpZ2hi b3IgUmVnaXN0cnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPmFzIGhvc3Qgcm91 dGVzIGluIHRoZSBSSUIocykuIFRoZSBob3N0IHJvdXRlcyBhcmUgaW5zdGFsbGVkIGFzIGNvbm5l Y3RlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQt aW5kZW50OjE4LjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+cm91dGVzLiBXaGVuIHRoZSBO ZWlnaGJvciBSZWdpc3RyeSBlbnRyeSBpcyByZW1vdmVkLCB0aGUgcm91dGUgaW4gdGhlIFJJQjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50 OjE4LjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+bXVzdCBiZSByZW1vdmVkIGFzIHdlbGwu PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRl bnQ6MTguMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVy Om5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjE4LjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBj bSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+wqAgKy0tLS0tLS0tLS0tLS0rwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAr LS0tLS0tLS0tLS0tLSvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVy Om5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPsKgwqB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDC oMKgwqDCoCBJbmplY3TCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKg wqB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwtLSvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoCDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1p bmRlbnQ6MTguMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgfMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCB8wqAgfMKgwqDCoMKgwqAgJmx0Oz09PcKgwqDCoMKgIHzCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0O2JvcmRl cjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz7CoMKgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqAgfC0t K8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PsKgwqB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoCB8wqAgfMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0 LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqB8wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHzCoCB8wqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDC oMKgwqDCoCDCoMKgwqB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9y ZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqArLS0tLS0tLS0tLS0tLSvCoCB8wqAgfMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgKy0tLS0tLS0tLS0tLS0rwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWlu ZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqDCoMKgwqB8wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHzCoCB8PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7C oMKgwqDCoCArLS0tLS0tLS0tLS0tLSvCoCB8PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6 MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciJz7CoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7 Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqDCoMKgwqDCoMKgICstLS0tLS0tLS0tLS0tKzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50 OjE4LjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0O2JvcmRlcjpu b25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz7CoCBSSUJzIGluIGHCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBOZWlnaGJvciBSZWdpc3RyeTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjE4LjBwdDtib3JkZXI6 bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+wqAgNkxSIG9yIDZMQlLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHNhbWUgcm91dGVyPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0O2JvcmRlcjpub25lO3Bh ZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5k ZW50OjE4LjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+VGhlIDZMQlIgbWF5IGFnZ3JlZ2F0 ZSB0aGUgaG9zdCByb3V0ZXMgYXMgb25lIGNvbm5lY3RlZCByb3V0ZSB0byB0aGUgPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0 O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz53aG9sZSBwcmVmaXggb24gaXRzIDZMb1dQQU4gaW50 ZXJmYWNlIHRoYXQgc2VydmVzIHRoZSBzdWJuZXQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0O2JvcmRlcjpub25lO3BhZGRp bmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlJvdXRpbmcg cHJvdG9jb2xzIHN1Y2ggYXMgUlBMIG1heSB0aGVuIHJlZGlzdHJpYnV0ZSB0aGUgY29ubmVjdGVk IHJvdXRlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4 dC1pbmRlbnQ6MTguMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5mcm9tIHRoZSBSSUIocykg dGhhdCB0aGV5IHNlcnZlIGFuIHRodXMgaW5qZWN0IHRoZSBob3N0IG9yIHByZWZpeCByb3V0ZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVu dDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPmluIHRoZWlyIG93biByb3V0aW5nIGZh YnJpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0 LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjE4LjBwdDti b3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+TkQgY2FjaGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFk ZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPi0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWlu ZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkEgNkxSLzZMQlIgbWF5IHN1cHBv cnQgdGhpcyBzcGVjaWZpY2F0aW9uIGFuZCBOZWlnaGJvciBEaXNjb3ZlcnkgYXMgc3BlY2lmaWVk PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRl bnQ6MTguMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5pbiBSRkMgNDg2MSBvbiBhIHNhbWUg aW50ZXJmYWNlLiBJbiB0aGF0IGNhc2UsIE5EIGNhY2hlIGVudHJpZXMgY2FuIGJlIGdsZWFuZWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVu dDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPmZyb20gdGhlIHJlZ2lzdHJhdGlvbiBw cm9jZXNzLCBhbmQgZW50cmllcyB0aGF0IGFyZSBzdWJqZWN0IHRvIE5VRCBtaWdodCBiZSA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDox OC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPmNsZWFuZWQgZnJvbSB0aGUgTmVpZ2hib3Ig UmVnaXN0cnkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n dGV4dC1pbmRlbnQ6MTguMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4w cHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgICstLS0tLS0tLS0tLS0tK8KgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tLS0tLS0tLS0tLS0rwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n dGV4dC1pbmRlbnQ6MTguMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgfMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgIMKgwqDCoMKgwqDCoMKgwqDCoDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjE4 LjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgfC0tK8KgwqDCoMKgIEdsZWFuwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8 wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGlu ZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPsKgwqB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoCB8wqDCoMKgwqDCoCAmbHQ7 PT09wqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqB8wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIHzCoCB8LS0rwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjE4LjBw dDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg fMKgIHzCoCB8wqAgQ2xlYW7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjE4LjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBj bSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+wqDCoHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIHzCoCB8wqDCoCA9PT0mZ3Q7wqDC oMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0 LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqArLS0tLS0tLS0tLS0t LSvCoCB8wqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tLS0tLS0tLS0tLS0rwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKg wqDCoMKgwqB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoCB8PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0O2JvcmRlcjpu b25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz7CoMKgwqDCoCArLS0tLS0tLS0tLS0tLSvCoCB8PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0O2Jv cmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0 ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqDCoMKgwqDCoMKg ICstLS0tLS0tLS0tLS0tKzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J3RleHQtaW5kZW50OjE4LjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRl bnQ6MTguMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoCBOZWlnaGJvciBDYWNoZSBwcmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVu dDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgIEludGVyZmFjZSBpbiBhwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIE5laWdoYm9yIFJlZ2lzdHJ5PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6 MTguMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoCA2TFIgYW5kIDZMQlLCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHNhbWUgcm91dGVyPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0 O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFk ZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPkluIGEgbmV0d29yayB3aGVyZSBub2RlIG1pZ2h0IGJlIHNsZWVwaW5nIGZvciBh IGxvbmcgdGltZSwgTlVEIG1pZ2h0IHdyb25nbHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGlu ZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPmRldGVybWluZSB0aGF0IGEgbm9kZSBpcyB1bnJlYWNoYWJsZSBzbyBpdMKgIG11c3Qg YmUgcG9zc2libGUgdG8gdHVybiBvZmY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoCB0aGUgY2xlYW5pbmcg b3BlcmF0aW9uLiBJbiBtb3N0IGNhc2VzLCB0aG91Z2gsIGl0IGlzIGV4cGVjdGVkIHRoYXQgc2xl ZXBpbmcgbm9kZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoCBlbmQgdXAgcmVjZWl2aW5nIHRoZWlyIHRy YWZmaWMsIGFuZCBzaG91bGQgc3RheSBhd2FrZSBsb25nIGVub3VnaCB0byBhbnN3ZXIgdGhlPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYm9yZGVyOm5vbmU7 cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPsKgwqAgcG9sbGluZy4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0O2JvcmRlcjpub25lO3BhZGRpbmc6 MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjE4 LjBwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MTguMHB0O2JvcmRlcjpub25l O3BhZGRpbmc6MGNtJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4wcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nbXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRl cjpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMzEuMHB0IDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoxOC4w cHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNs YXNzPU1zb0xpc3RQYXJhZ3JhcGg+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTGlz dFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSdtc28tbGlzdDpJZ25vcmUnPjQpPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBS b21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT5Ub3BvbG9neSBzdXBwb3J0ZWQgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxl ZnQ6MTguMHB0Jz5UaGUgZG9jIGNvdWxkIGJlIG1vcmUgY2xlYXIgYWJvdXQgd2hhdOKAmXMgaW4g d2hhdOKAmXMgb3V0LiBJbiBwYXJ0aWN1bGFyLCBpdCBhcHBlYXJzIHRvIG1lIHRoYXQgd2UgYmV0 dGVyIHNheSB0aGF0IHdlIHN1cHBvcnQgb25seSBvbmUgTEJSIGFuZCB0aGF0IHRoZSBzdXBwb3J0 IHRvIHNjYWxlIHRvIG1vcmUgdGhhbiBvbmUgTEJSLCBmb3IgaW5zdGFuY2UgdXNpbmcgYSBiYWNr Ym9uZSwgaXMgb3V0IG9mIHNjb3BlLiBXZSBjYW4gYWxzbyBzYXkgdGhhdCB0aGUgTEJSIGtub3dz IGFsbCB0aGUgYWRkcmVzc2VzIGluIHRoZSBzdWJuZXQgdGhhdCBpdCBjb3ZlcnMsIGFuZCB0aGF0 IGl0IGNhbiBlaXRoZXIgcmVwcmVzZW50IHRoZW0gb3ZlciBhIGJhY2toYXVsIG9yIGEgYmFja2Jv bmUsIG9yIGFnZ3JlZ2F0ZSB0aGVtLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJh Z3JhcGg+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD7igJw8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoCBJbiBhIG1lc2gtdW5kZXIgY29u ZmlndXJhdGlvbiBhIDZMQlIgaXMgYWN0aW5nIGFzIHRoZSBJUHY2IHJvdXRlcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoCB3aGVyZSBhbGwgdGhlIGhvc3RzIGlu IHRoZSBMb1dQQU4gYXJlIG9uIHRoZSBzYW1lIGxpbmssIHRodXMgdGhleSBhcmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqAgb25seSBvbmUgSVAgaG9wIGF3YXku wqAgTm8gNkxvV1BBTiBSb3V0ZXJzIGV4aXN0IGluIHRoaXMgdG9wb2xvZ3kgYXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqAgZm9yd2FyZGluZyBpcyBoYW5kbGVk IGJ5IGEgbGluay1sYXllciBtZXNoIHJvdXRpbmcgcHJvdG9jb2wuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+4oCcPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTGlzdFBhcmFncmFwaD49Jmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJh Z3JhcGg+4oCcPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqAgTWVzaC11bmRl ciBjb25maWd1cmF0aW9ucyB2YXJ5IGEgbG90LCBkbyBub3QgZ3VhcmFudGVlIGFueSB0byBhbnkg PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgwqBkaXJlY3QgY29u bmVjdGl2aXR5LCBhbmQgbWF5IGdyb3cgdmVyeSBsYXJnZS4gSXQgaXMgZXhwZWN0ZWQgdGhhdCA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqDCoGEgaG9zdCBpcyBv bmUgbWVzaCB1bmRlciBob3AgYXdheSBmcm9tIGF0IGxlYXN0IG9uZSA2TFIsIGFuZCB0aGF0PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgIGFsbCB0aGUgNkxScyBo YXZlIGEgbWVzaCB1bmRlciBjb25uZWN0aW9uIHRvIHRoZSA2TEJScy4gQ29uZmlndXJhdGlvbnM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqAgd2l0aCBtb3JlIHRo YW4gb25lIDZMQlIgYXJlIG5vdCBzdXBwb3J0ZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPuKAnDxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29M aXN0UGFyYWdyYXBoPuKAnDxvOnA+PC9vOnA+PC9wPjxwcmU+wqDCoCBvwqAgQSBuZXcgb3B0aW9u YWwgbWVjaGFuaXNtIHRvIHBlcmZvcm0gRHVwbGljYXRlIEFkZHJlc3MgRGV0ZWN0aW9uPG86cD48 L286cD48L3ByZT48cHJlPsKgwqDCoMKgwqAgYWNyb3NzIGEgcm91dGUtb3ZlciA2TG9XUEFOIHJl dXNpbmcgdGhlIGFib3ZlIEFkZHJlc3MgUmVnaXN0cmF0aW9uPG86cD48L286cD48L3ByZT48cHJl PsKgwqDCoMKgwqAgb3B0aW9uLjxvOnA+PC9vOnA+PC9wcmU+PHAgY2xhc3M9TXNvTGlzdFBhcmFn cmFwaD7igJw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPj0mZ3Q7PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD7igJw8bzpwPjwvbzpwPjwvcD48 cHJlPsKgwqAgb8KgIEEgbmV3IG9wdGlvbmFsIG1lY2hhbmlzbSB0byBwZXJmb3JtIER1cGxpY2F0 ZSBBZGRyZXNzIERldGVjdGlvbjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqDCoMKgIGFjcm9z cyBhIGxhcmdlIDZMb1dQQU4gd2l0aCBtdWx0aXBsZSA2TFJzIHJldXNpbmcgdGhlIGFib3ZlIEFk ZHJlc3MgPG86cD48L286cD48L3ByZT48cHJlPsKgwqDCoMKgwqDCoFJlZ2lzdHJhdGlvbiBvcHRp b24uPG86cD48L286cD48L3ByZT48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPuKAnDxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9TXNvTGlzdFBhcmFncmFwaD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29M aXN0UGFyYWdyYXBoPuKAnDxvOnA+PC9vOnA+PC9wPjxwcmU+wqDCoCBPcHRpb25hbGx5IHRoZSBS b3V0ZXIgQWR2ZXJ0aXNlbWVudCBtZXNzYWdlcyBjYW4gYmUgdXNlZCB0bzxvOnA+PC9vOnA+PC9w cmU+PHByZT7CoMKgIGRpc3NlbWluYXRlIHByZWZpeGVzIHRvIGFsbCB0aGUgNkxScyBpbiBhIHJv dXRlLW92ZXIgdG9wb2xvZ3kuwqAgVGhpczxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgIGlzIG9w dGlvbmFsIGJlY2F1c2UgdGhlcmUgYXJlIGxpa2VseSB0byBiZSBvdGhlciBtZWNoYW5pc21zIGZv ciBzdWNoPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgaW5mb3JtYXRpb24gZGlzdHJpYnV0aW9u LjxvOnA+PC9vOnA+PC9wcmU+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD7igJw8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPj0mZ3Q7PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTGlzdFBhcmFncmFwaD7igJw8bzpwPjwvbzpwPjwvcD48cHJlPsKgwqAgT3B0aW9uYWxs eSB0aGUgUm91dGVyIEFkdmVydGlzZW1lbnQgbWVzc2FnZXMgY2FuIGJlIHVzZWQgdG88bzpwPjwv bzpwPjwvcHJlPjxwcmU+wqDCoCBkaXNzZW1pbmF0ZSBwcmVmaXhlcyB0byBhbGwgdGhlIDZMUnMu IFRoaXM8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoCBpcyBvcHRpb25hbCBiZWNhdXNlIHRoZXJl IGFyZSBsaWtlbHkgdG8gYmUgb3RoZXIgbWVjaGFuaXNtcyBmb3Igc3VjaDxvOnA+PC9vOnA+PC9w cmU+PHByZT7CoMKgIGluZm9ybWF0aW9uIGRpc3RyaWJ1dGlvbi48bzpwPjwvbzpwPjwvcHJlPjxw IGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+4oCcPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlz dFBhcmFncmFwaD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBo PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+4oCcPG86cD48 L286cD48L3A+PHByZT7CoMKgIFdoZW4gYSA2TFIgdGhhdCBpbXBsZW1lbnRzIHRoZSBvcHRpb25h bCBtdWx0aWhvcCBEQUQgcmVjZWl2ZXMgYW4gTlM8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoCBm cm9tIGEgaG9zdCAodGhlIEFSTyBoYXMgTGVuZ3RoID0gMikgYW5kIHRoZSA2TFIgZG9lcyBub3Qg YWxyZWFkeTxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgIGhhdmUgYSBOZWlnaGJvciBDYWNoZSBl bnRyeSBmb3IgdGhlIGhvc3QncyBJUHY2IGFkZHJlc3MsIHRoZW4gdGhlIDZMUjxvOnA+PC9vOnA+ PC9wcmU+PHByZT7CoMKgIGZvcm1zIGFuZCBzZW5kcyBhbiBOUyB0byBhdCBsZWFzdCBvbmUgNkxC Ui4gPG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSd0ZXh0LWluZGVudDozNi4wcHQnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD7igJw8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPj0mZ3Q7PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTGlzdFBhcmFncmFwaD7igJw8bzpwPjwvbzpwPjwvcD48cHJlPsKgwqAgV2hlbiBhIDZM UiB0aGF0IGltcGxlbWVudHMgdGhlIG9wdGlvbmFsIG11bHRpaG9wIERBRCByZWNlaXZlcyBhbiBO UzxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgIGZyb20gYSBob3N0ICh0aGUgQVJPIGhhcyBMZW5n dGggPSAyKSBhbmQgdGhlIDZMUiBkb2VzIG5vdCBhbHJlYWR5PG86cD48L286cD48L3ByZT48cHJl PsKgwqAgaGF2ZSBhIE5laWdoYm9yIENhY2hlIGVudHJ5IGZvciB0aGUgaG9zdCdzIElQdjYgYWRk cmVzcywgdGhlbiB0aGUgNkxSPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgZm9ybXMgYW5kIHNl bmRzIGFuIE5TIHRvIHRoZSA2TEJSLiBBIGNvbmZpZ3VyYXRpb24gd2l0aCBtdWx0aXBsZSA2TEJS czxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgIGlzIG5vdCBzdXBwb3J0ZWQgYnkgdGhpcyBzcGVj aWZpY2F0aW9uLiBJdCBpcyBleHBlY3RlZCB0aGF0IHRoZSA2TEJScyA8bzpwPjwvbzpwPjwvcHJl PjxwcmU+wqDCoMKgd291bGQgc3luY2hyb25pemUgcHJvYWN0aXZlbHkgb3IgcmVhY3RpdmVseSB0 aGVpciBNYXN0ZXIgTmVpZ2hib3IgPG86cD48L286cD48L3ByZT48cHJlPsKgwqDCoHJlZ2lzdHJp ZXMgYmV0d2VlbiB0aGVtc2VsdmVzIHdpdGggbm90IGFkZGl0aW9uYWwgYWN0aW9uIGJ5IHRoZSA2 TFIuPG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSd0ZXh0LWluZGVudDozNi4wcHQnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD7igJw8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDox OC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+NSk8c3BhbiBzdHls ZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPm1lcmdpbmcgdGhlIGRpc3NlbWluYXRpb24g cHJvY2VzcyB3aXRoIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBtYXkgc2xvdyBkb3duIHRoZSBh ZG9wdGlvbiBvZiB0aGUgbGF0dGVyLiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFy YWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDoxOC4wcHQnPkFsc28sIHNvbWUgY29uZmlndXJhdGlv bnMgdXNpbmcgYW4gYWx0ZXJuYXRlIGRpc3NlbWluYXRpb24gcHJvY2VzcyBtaWdodCBub3QgcmVx dWlyZSB0aGF0IGZlYXR1cmUgZnJvbSBORC4gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlz dFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTguMHB0Jz5TbyBJ4oCZZCBzdWdnZXN0IHdl IG1ha2UgaXQgYSBzZXBhcmF0ZSBzcGVjIGFuZCB3ZSBmb2N1cyBkZWVwbHkgb24gdGhlIHJlZ2lz dHJhdGlvbiBmb3IgdGhlIHRpbWUgYmVpbmcuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxz cGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD01NDMgc3R5bGU9J3dpZHRoOjQwNy4yNXB0Jz48 dHI+PHRkIHN0eWxlPSdwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSc+PHRhYmxlIGNsYXNzPU1zb05v cm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD02MDAg c3R5bGU9J3dpZHRoOjQ1MC4wNXB0Jz48dHI+PHRkIGNvbHNwYW49MyBzdHlsZT0ncGFkZGluZzow Y20gMGNtIDBjbSAwY20nPjwvdGQ+PC90cj48dHIgc3R5bGU9J2hlaWdodDo5NC4wNXB0Jz48dGQg bm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGNtIDBjbSAxMS4yNXB0IDE4LjBwdDto ZWlnaHQ6OTQuMDVwdCc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4 LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz5QYXNj YWwgVGh1YmVydDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz48YnI+PGI+RW5naW5lZXIu c29mdHdhcmUgRW5naW5lZXJpbmc8L2I+PGJyPjxiPlByb2R1Y3QgRGV2ZWxvcG1lbnQ8L2I+PGJy PjxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSdjb2xvcjoj NjY2NjY2Jz5wdGh1YmVydEBjaXNjby5jb208L3NwYW4+PC9hPjxicj5QaG9uZTogPGI+KzMzIDQg OTcyMyAyNjM0PC9iPjxicj5Nb2JpbGU6IDxiPiszMyA2IDE5OTggMjk4NTwvYj48YnI+PGJyPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L3RkPjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFk ZGluZzowY20gMGNtIDcuNXB0IDE1LjBwdDtoZWlnaHQ6OTQuMDVwdCc+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+ PGI+PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjYnPkNpc2NvIFN5c3RlbXMgRnJhbmNlPC9zcGFu PjwvYj48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+PGJyPlZpbGxhZ2UgZCdFbnRyZXByaXNl cyBHcmVlbiBTaWRlPGJyPjQwMCBBdmVudWUgZGUgUm91bWFuaWxsZSA8YnI+QmF0aW1lbnQgVCAz IDxicj4wNjQxMCA8YnI+QklPVCAtIFNPUEhJQSBBTlRJUE9MSVM8YnI+RnJhbmNlPGJyPjwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiM2NjY2NjYnPjxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL2dsb2Jh bC9GUi8iPjxzcGFuIGxhbmc9RlIgc3R5bGU9J2NvbG9yOiM2NjY2NjYnPkNpc2NvLmNvbTwvc3Bh bj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC90ZD48dGQgd2lkdGg9MTg2IHN0eWxlPSd3aWR0aDoxMzkuNzVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDBjbTtoZWlnaHQ6OTQuMDVwdCc+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIic+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPjxpbWcgYm9yZGVyPTAgd2lkdGg9 MTY0IGhlaWdodD0xMDggaWQ9IkltYWdlX3gwMDIwXzEiIHNyYz0iY2lkOmltYWdlMDA0LnBuZ0Aw MUNBRjlDOS4yMkIzMDIyMCI+PG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48L3RhYmxl PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO2Rpc3BsYXk6bm9uZSc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxs c3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NzE5IHN0eWxlPSd3aWR0aDo1MzkuMTVwdCc+ PHRyIHN0eWxlPSdoZWlnaHQ6OTAuOHB0Jz48dGQgd2lkdGg9NzE5IHN0eWxlPSd3aWR0aDo1Mzku MTVwdDtwYWRkaW5nOjBjbSAxOC4wcHQgMGNtIDE4LjBwdDtoZWlnaHQ6OTAuOHB0Jz48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA5OTAwJz48aW1nIGJvcmRlcj0wIHdpZHRoPTE4IGhl aWdodD0xOSBpZD0iSW1hZ2VfeDAwMjBfMiIgc3JjPSJjaWQ6aW1hZ2UwMDMuZ2lmQDAxQ0FGOUI0 LkFBMjM3MzgwIiBhbHQ9IlRoaW5rIGJlZm9yZSB5b3UgcHJpbnQuIj48L3NwYW4+PHNwYW4gbGFu Zz1GUiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiMwMDk5MDAnPlRoaW5rIGJlZm9yZSB5b3UgcHJpbnQuPGJyPjxicj48L3NwYW4+ PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOiM5OTk5OTknPkNpc2NvIFN5c3RlbXMgRnJhbmNlLCBTb2Npw6l0 w6kgw6AgcmVzcG9uc2FiaWl0w6kgbGltaXTDqWUsIFJ1ZSBDYW1pbGxlIERlc21vdWxpbnMg4oCT IEltbSBBdGxhbnRpcyBaYWMgRm9ydW0gU2VpbmUgSWxvdCA3IDkyMTMwIElzc3kgbGVzIE1vdWxp bmVhdXgsIEF1IGNhcGl0YWwgZGUgOTEuNDcwIOKCrCwgMzQ5IDE2NiA1NjEgUkNTIE5hbnRlcnJl LCBEaXJlY3RldXIgZGUgbGEgcHVibGljYXRpb246IEplYW4tTHVjIE1pY2hlbCBHaXZvbmUsIEZv ciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86PGJyPjwvc3Bhbj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OiM5OTk5OTknPjxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19i dXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbCI+PHNwYW4gbGFuZz1GUiBzdHlsZT0nY29sb3I6 Ymx1ZSc+aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2Fs L2NyaS9pbmRleC5odG1sPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDk5 MDAnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L3RkPjwvdHI+PC90YWJsZT48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1GUj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC90ZD48L3RyPjwvdGFi bGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RlI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUZSPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_002_01CAF9B8.B56B1190-- ------_=_NextPart_001_01CAF9B8.B56B1190 Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.gif Content-Location: image003.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CAF9B8.B56B1190 Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.png Content-Location: image004.png iVBORw0KGgoAAAANSUhEUgAAAKQAAABsCAYAAADkDhmYAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABgJSURBVHja 7Z0HeJVF1sdVbJ9rWctaVlEpYgOxLaCAuvjpolgAC12luK4sghjAANKkSZGW3hNSICGQ3hNCOkkg vRES0nvvyU35f+cMuSmkAslnrsx5niEhuXfeue/85tSZNzdBipShIb9u27btppvkfZAigZQiRQIp RQIpRYoEUooEUooUCaQUCaQUKRJIKRJIKVIkkFIkkBJIKRJIKVIkkFIkkFKkSCClSCClSJFASpFA SpEigZQigZQiRQIpRYoEUooE8v9dmpqb0dzSopJjb6Fx8/glkH8SqVc0Ii2/CNlFpWhWsYnlRZRT XIa0vCLUNSgkkKoudQoF4jNyYel9Fif9zyOjoASNjU0qMfbGpiZkFZbCLiAC5l4hiE3LRm19gwRS lYW1i6lHEJbsM8V/j1jCKSQa5VU1KjH2ypo6uIbG4gcNKyzeawIj1wABqARSheX8hXT897Al/rF8 Byav/A2/HnVCen6xSow9m+DbaeGCKav24PXvd+C7g+YITbgkgVRlcQmNwTs/7cPIhesxgtqc7XqI Ts1SibEnkKuxYKcBRixYL8Y/9cc9sAuMlECqspzwP4dXvvsVTy1QxxNz1+Ff6gcRfiFNJcYeRQtn xobDeGLOOoJSHS99uxWWPmclkKosJwMjhLlj7fjk/J/xIU3w+eR0lRh7zKVsfPKLBobP+1loSF5Y x3zDJJCqLKcIyH8s39kG5IyNR1QKyE83aeLJViBf/c92HJdASiAlkBLIPoVrLi39qLxcK5Atg1zV 6U//1wokd62iRSnVBbKovAqFpRV9lgOvBcgGRRNyS8pRXl07KGOvqKlFbnE56hsaBxxIvh2FZZWi qSiTqgUk13TzSyrgER4Hl5AYZBaWQNHUNGBAcmUnMSMPdvS+gJhklFXVDFgNnLthyIPiLorqS3x6 Tq/lwKsFkis72UVlIpnuRi23uEwVa+CqBWRFTR08z8Vjnb4tVmtbwz4oEsUVVQMGZEZBMUzcA0Uy fbu5E8IS00QtfCCkobFJXHunpTOWU/8Grv6iRj1QQJZUVsM5JBpqOjZYo2tDUMbQAlCNqpTKApme X4LdVq74p9p+TP1xLzYa25FGyx0wIFkrckXkjR9246MNR2DkGojyqoEx3ZW1dTjqGSxSOZN+2IWl +83gG5k0YEAmZ+Vjq5kD3l69D2//tE8sqNTcQgnkYErkxUzM3a6P0V9twKhFG/ARAXYm6sKAAcmb GN5cuVv0/ew3m4QWZn9yIKSwvFJo9ucWbxLjn/DfnTByCxwwIANjUzBrsxZG09hHUf+fb9UhDa9y pcahASR7af3xd4LjUzBtzX4Mn7cOTxFgE1fshPPZmAEDUsPuNIH4iwCAKyQLdxsig/zUvqQ/Y2ew F+8zERWjUYvWCyj323gOGJDsykxe9Zu4L/xZ31q9lxZrUp/j4i15LUMnLB8aQLL2yMgvpshT0SeQ 7679nSaJgVQXps9lAIHUtD8tNNhI0jLDCZxFvxmJwKk3qaSomX3BvqLyPAJyyX5TsZgYxme+3oj9 JwYWyCk/7mkDks12X0Cyf8xb8grKKiSQYnXSymRnnKPmYz6hSMjI6TWICElIxXvrDoib/vQCdWFe OaocKCC1HHzxwpLNwmQzCF/vMe4VyOq6eoSSWbQgU8+Lpaqurlcgl/1uJsbBQLImPmDrNWBAep1P EFqR7wvX7tnP9ovu2Z3hICspMw/HT4fBLSwWRRQcDoFd9X8skBwF2viFi0BiwS5D7KAItLfdOEMJ yEYydb7kv7JfOH+ngYhuvSMSoOhhA/BQA5LTTr8dc8VCuu//PnAUVqdDhXK4oYG8RKaO/arLE7QJ ry/fgaNewSoBJOcQt1s4i9c/t/gXPEeAbTKx71FLDjUgua+JK3ZhDI1j9KKNwl9Oysq7sYFMzirA zC1aePiz1cJnG0nOvo7TGZUAsoaAXEva8bEv1KjvdXj0czWs0jwmKjGqAKQxRfjsxz4+dy3d/58w Y8MRxKVl39hApuQUYt5OfRGkMARjl22BkVuASgBZS0D+QhqRYWHAeM8im2/ON6oCkJziGv/vbUIJ 8DU+36YjNgXf8EDO2aFH2nGtgOCFpZth6Orf4+uD41Pbo+wFgxdlj+pHlM1AbjC2EyAyYE9T/2v0 TvQK5JVR9u+DEmWr02dV7zPK5iT9uG+3YgQByZ919lZtcSDuhgbyYnYhvtyuiyfmrBU3/fklm2Dg 0huQQycPyUCuNzolxjFKaJl1UNO16RHIwc5DerTmIflzDu9HHtLMI1hYpBELL++mn0WuEwc6NzSQ nAPj04BjSFuwVuIDTdZnwnt8fcTFTHEuRlQjqM0Y4ErNUc8QUTYUlZqvf8GPWj1Xajg9xUCN/3ab eP24pVuwy8pVpIK6k8uVmhMU/GwSlRSu1Bi6BgwYkIGxFzFzs5YYC/f/2VYdkZLqSXgDCZ83GvXV ejzz1UYRaafkFNzYQPLGCB3HM5iufkiAwJsOQsgs9yRcy95l6SpuJMO7wciuV7/naoH0j0kWE8Nj YSff0CUAZT3Usnl3jWNQFObu0BfR6hfbdHEqIAINPeRRWXOaeQTh440amEiuBh/NPR2ZOGBAXsjK xxZTB7z1416hHfmEZWpOz7Xs8KR0rKQgjP3w99cdJOvgg4LSPzxB/scCWdvQgCAyw5wuWX7IEmae Qb2ePeZqiHtYHNbonqCI9rgArqiicsCA5COyfP75+4MW2GbmKI6d9pSo53JbQkYeDp30wncHzPG7 jQfi0rN7fDoGJ6L5gBlvevgP9a/n7IdLvWx+uJbdPo7BUVhNWv0nbWvyraPF9rmehPdkWniHiJ1N G2lh+8dcQE3dH/4ggqFRqfElX4f3CF7Iyuu1UsM1Yw4O3AhKp+BoYfJ72w/Jpw5f7nDq8P0+Th1y bjEhPRen/M/DP7rv/ZBsnhlwW79zCEtKQ1Vtz5UaBpgfUhAQmyyeohHXx5Mo+NThh+LU4VoROI3r 49ShovVJF84hMXAlv5ofktDY1HONvaGxkXz4fNgHRsInIlFYq+bmG7xSo5RSmijeUMo3qU9p3RVd 0I8d444hUeTo7xEakqHkSDIqJbPX97DJ5cks6+e2sxqCMqeoFFU9+I7dafmcorI+6/YcYHz5qy5F 7+pCQ05asRu2BHJfC7ygbcd433BxVYkXeOkfX6EZWkAqNUj/X9u/17M/yo8h4XwbH4dVNzjZrz2C V1vTHYzXZ5C/zKaUx82B06LdRgiIudiv+3h193JIHXb4c5865B3g2g6+IjL/Zo8xbCiCHwL12n4J uwusEZfQgmJNeYSCjku5RX/WqboxgKyur8c58vF0nc6ICDeZfKaGATqSMNjC5vQiRcnmnsEiExHa h48qgVQBYXPEvh1va0shGBWNqgFjG5QUqKTmFAh/ktNGQ8y8SiCveWIJxMYm1Xgu5JXSRJFyg4ot JAmkFAmkFCkSSCkSyKEsTXV1aKypQRNF0+L76mq0DKKvyNdRXq/xOq/XrFCI9zfV1orG3zc3XH3p TrxXOSb6qqiqQovq+pyqB6Q4MksTV5WVhWwfH6Q5OCDDxQXpTk7UnFEUGSkmpqW7mjL/iQ2auIby ctQVF4vG3zPMLb0cZW1ubEJ1Xh5yzpxpv56zM9IdHVFw7hwaKqvQ3E8wmwmWupIS5AWHiDFnuLqK lkbf5wUGijH1Byi+XnVuLrJ5TDQOMSbRXFEUFSU+kwRysDWiohHFKam4YGeP4G2/wm3ePNi/9RZO TZyIUxMmwOFf0+G3ejVS7exQV1jYCUSlRuUJPKuuDreZM+FKLVhNDRnu7mio6H6nSx39PCMgEKH7 9sN94aK269lRc3z/ffh8vxwxJqYoTrzQq7bklE1lbh7SvL1x7sABeC5ZCscPZ8D+vfdF47F7L12G eANDlCYkEnDNPS5I7icnMAgxOrrw/vY72L/zDo1pEuyoH5cv5iBow0ak0sIpu3QJTSryVydUDsh6 0nrpp30RsHYdTtKNNxs5Cvr33gtNGv7h1qZ1880wGzUavj+sRElCQhcgFZWViDc0hPW4cThAr/+d mtXo0Yg6eBA1BV33AlbRxCcet4b7oq9h/sJY6P/1fmjQew61Xo+vrXv/A7B5czKSjtugsYf6dCOZ 5/yYWJw7dAROs2fD4oUXYfDAg9C+9VbRHzdNGrvRo4/BefZnSHFwJJega22cES26kIxITS140uI4 QRAaP/Y4tOj9R1rHo3/vX2E+5lk4TZ+O4E2bkeF7RnxuCeQACbNURzc0xcMDbosWwei++6BNk6dL w9ZubTqtX3lidO64A45ffIn8iIguffHEJJqZ4dSkSWLyGASb8eMRo6WFmqLOZbn6qmok2zvA/sOP oH/PPeIa3Pi6esOGQY9g0rvtNmjccguMaGFEHT4ChULRjVZXIIfMut/GTbAYNx469D6dDmNWfq/Z +n8rgizG7CgUVzwoirVvYWwcgrfvwLHXXofeHXeKsXT87Fod+tSje2T82N/hsegrpJNL0FChElAO fSDrydlP8fCE69y5pFUeEBOn1QFGA4LFlLSlyZNPiQni39nPmoW88+e7akhy+JPMzWE3eXLbJNq+ 9hpidXRQewWQrIkCftkEk0ceFeBqtcJoPnIkTv3ve7Ajc8vN/KXxQuPFGRh1MbPs5+WST+v7888w Gz0GWgRyx7Hr3XknjJ94EmYjRkHvrrvE7yxefQ3RxiY01vaaO4++LC0NQet+hunTT0OHFkLHftoW 5rBbuwBq9NBD8CBtmunnL1weCeR1SsnFFJxWWwvDBx8SMOq03mjWTtakKbz+/R2Cf90h4HFnn3L6 B/BTX48ipcnu8EjZ/gLJgUeqtw+c5tAiIE0kYKTrmY8Zg4D165Hq7kG+oA8ueXoj1tgUEUc0kRca ToFR59JeHQVM4Uc0YPbi2E4LSfe222Hx/AtwXbAQAWRWefxey76F40cfw4O+JrPJ7nCcto7GnXjS DjYE6+GO/ZAWPPr0CDhMmwbvefPhQZ//xBuTYUQLV6l5eTGZ/P1xhJJmrUjPkEBej3BqJNXZBSem vAVtMo1Kk6lL2sSW/LZIPX3kRcegIjsbpeTA5547jxQ3N6T7nEZ1fsE1A9lY30Dm2hH2BIgSSNZm 1lOnItbUDDUlpcIUizEShA2kzRS1tZ0idWFiyW90/+pr6P7PXe0m//Y7YEULKWjnLmQEBaOMICnP zEI+fY40Hx+kuLqhKC4eTR380cK4OPisWCnAUppkhtqKNLO/+gZcIpNcGhuL/LNnEW1kDEfyQ43I t9UhYHnsBrffDpdPPkG6m7sE8nqkIicbYbt/gyk5+0rtqE9g2r79NqIoGq2iQER5ZECkgwgCBoMB ae7GPPVbQ1KfGV7ecP/ySxi1mlJduq4xmT/3+QsRa26JrJAQVObk9HhkobasDInWJ3ByypROvq7F 2LECxqLk5E5BEPej4JQUjbGR4W5dRPwvR8zHx46D5q23XfYPb7oZ5s+/iKAtW8kSJIrPzIuuuVGB 6sIixFsdg/0HHwh3Rnld82efQ7S2Tq/pLQlkH8KR6ekVP8Do7nsEkNwMyHQGki9VkXf1J+R6A/LK oKaUgAlUWwN9ut6hDsGHyUN/g/WEiXD+9FORYko4dhxlmV13obPWDjtwkLTYC+0B1803wY3cgNyI yH6PuYG0day+AcwefFCYa22xKIfRwliArNDuz9iwxg3btw8WzzzTZt71739QmO2Wob3JZGgDmU0m 2JN8RKN77hU3lv0hQzKdcVra19Tf1QDZQFon2dYWpyZPgT75rzodAoW2Sb77bti89TZCd+1GcXyC 8D2VUpaejmD6+dHRo9veo0tABqmpiUR6f6W2vAJRmlo4+ujl4Eq5KEM2bERVYfcbdhV19Uh2coLt G2+0B2R33Y2zmzdLIAcDyHg9vUEHkk1lTWEhUhwd4f3DSjKRzwuzfWVkq00+ocVTTyGcXIvyrOyu QLZqKWWUHrx2bbc5xl6B1NDsHsiCwp6BpHHbTprUDuRf/iKBvF7JJ2fed+WqziabHPSwbdtQW1py 1f1dDZBt72loINchBrEmJvCjsbjOnIVjBJleK5AarV8dP/4ElyjybmmtjFSQfxl+6DCsXnyx3WRT 8/76G5E56K/U19aJiowpaWllhK0/bBh8vlmMwqiobt9TkZuHsIMHYTnm2bbFoHfffThL900CeR1S npWFUAoATB/7e1vimJPSTp98SibJGfXd/JUBzv1xBNzmvHfYZX0tQHYUDqJygkMQumULLEaOEpUW ndb0y3HyK2OMTMSmi8uarVz4l7Yc1NDvlRrVZsIEkR2ozOv66Ds+/MVjF6ZfWe6kz5NsexLHOHVE 11Ome2xeeQVRBw60ZxNahV2Ni86uFGnPhuF9f227rjFp8XMHD0kgr0caCLhEaxucmDJVVDi0W80e pz88liwVKRIOHurKygVQ5WnpyI+MQkF0DOopyr08y839Svt0ApIjVt6NwztxrtiBw8BkBwTC4dOZ 0GuNYnlMVi+/gkjSZA3VlxPaXEPOIng516hHvqYyZWVAkNjN+AixR81RkpKK2pJS1FGrIHNfGJeA 3PMRFJRkdvJH+TNxvtX4kUfaqzt33I5Tb76JBAtLlGdkoJ5MO7+PK1pe3y+H6eOPC3DFIqZ7Z/vP aUgisIf4MYihDSQnmgtjY+G7YgVMKMpUmj2+0SakNe2nvYuA9RtwXltHRLQB5Fd5/ud7BO/YiZKk pHYNeZV5SNauFaSd033P0CSewkVXd2SFhSEnIgL5FCHHkoazfvU1UaZUAmL1yquI0jOAorq9wlKV n4/wvXth+eyzbVE6N8P774ft2+/Ad81ahB/WwLkjGiKFw7lG/lmKi+vlVE6r8IJLsrKC7csvt7kI Ir9I/vTJN96E36ofEbZ3vygOOM6cCbPhw8U9UpYkjR9+BP7rfkZhx/q+BPIatWRFBVIo2nX813To 0gRoXhFUGD/6mCi3mY8dB2OaCH1y/u1nzUZuWFgnjXc1QIqSX3g4gjZvhf2Mj2FPfqPH0mWieZHv ZkfRqwFpnTb/jOvnpDFTXNw6aVTRT1AQfJYtEyU8jQ6+JCetDXnsXHoc/zJMnh4BA9KAlhMniRwr 5yM7fACUJycjYNUqGDz0UJfyKZtms1HPwGT4U9CjIEurA7T6994Hp9mf4ZKbOxpqhvwfUlKN3T7V efmkffRFQtzgrvaqh1Z3mysIWsfPv0De+Z43V5ycOLF9c8VLL4nNFVcmxrP8/ODFmzk4wr9lmMhH KpteB22nd9vtOEba8RxpaM7/XfmXL3mTBO/ecZkzF4aPP0F93dI23i6bK+h3lhMmIcbUrMvmCjbh 6f4BwlUx4Z1CNCadburZ2h3KilxudaTFxG5PTXHJUJ9m1QGSpYImO97cAu4UpZq/9LIox2m0brs6 0mELmu4dd8Jt8RLyx+K7AknaNt7ICNbjx+MgvZa3oFlRxBx16JBI8bQr1BZkkmZznT9fTO7+1i1n HRtf2+jhh2E3/UOc3b0HhTFxYiNvd1JbWopU0lC+a9bh2BuTYfDg3zqNnRuPR4Mgs3n3PSSSm9DY zXN/6smMZ5H/GkBm3ZpMvgG5MZod+lCmhTg/euz11+H13fe4cMoetcXFqjDFqgWkmFgKVDKDghGh o4fT5Lg7vvMO7Mn8OkydCnuKZtkUe86bL8CtIq16pfB2/xx/f4RRlOw5Zw48qJ1dvx6ZXl5ouGLP YGl6utDKrjNmiOCBr6FsfB1H0tYBamq4YO+AYjKnTYren9WjqK1DXkwsBTMWCFBfD2cy8XYUrDnQ uLmdpD6dZ30mIuECel1PJUmGvigxCfHHreH3009wmjat7R6Ivmhc3osXI5rMfnZoGOrKh8zfoPnz ASm0F01UE2mPKoquc3x9kenqiiwCKpOiyww3NxRHRV2uBfdwhEFEz3z2hADkxt/zz640tfx+NuN5 AQHiiAFfQ9n4Onx8opKiWzal/Q1cW1rTOnWkMfNDQ0U/WZ6eovE18kNCxO/6Og4h6vbUT3VOjjhW 0fEeZLq7934PJJCDJwwDH0vgQEIc9KqvH/BrtHS8hrLRdZr70Ih9D765c798rucacoRd7gHnQVX3 CRfyGKwUCaQUKRJIKRJIKVIkkFIkkFKkSCClSCClSJFASpFASpEigZQiRQIpRQIpRYoEUooEUooU CaQUCaQUKRJIKRJIKVIkkFIkkFKk/IGyWwIpZUgCuUs22YZAe08Ayf/IJttQaf8H38wkdlo9BugA AAAASUVORK5CYII= ------_=_NextPart_001_01CAF9B8.B56B1190-- From pthubert@cisco.com Mon May 31 01:36:02 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2ADD3A69EB for <6lowpan@core3.amsl.com>; Mon, 31 May 2010 01:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.944 X-Spam-Level: X-Spam-Status: No, score=-8.944 tagged_above=-999 required=5 tests=[AWL=1.655, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgxbugmxgSH7 for <6lowpan@core3.amsl.com>; Mon, 31 May 2010 01:36:01 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D85FB3A699A for <6lowpan@ietf.org>; Mon, 31 May 2010 01:36:01 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGIRA0yrRN+K/2dsb2JhbACeM3GmfpkrhRYE X-IronPort-AV: E=Sophos;i="4.53,332,1272844800"; d="scan'208";a="137228853" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 31 May 2010 08:35:50 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o4V8ZZEM018659; Mon, 31 May 2010 08:35:50 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 10:35:45 +0200 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, 31 May 2010 10:35:40 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02015B3F@XMB-AMS-107.cisco.com> In-Reply-To: <4C02648A.5060800@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] SLLA option in NS Thread-Index: Acr/+hEjIK9U/m5ISUKlW0y9YR6BtwAoR3vg References: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> <4C02648A.5060800@oracle.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , "Tetsuya Murakami" X-OriginalArrivalTime: 31 May 2010 08:35:45.0225 (UTC) FILETIME=[432F1B90:01CB009C] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] SLLA option in NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 31 May 2010 08:36:02 -0000 OTOH,=20 oDAD (RFC 4429) has it that: * Never using an Optimistic Address as the source address of a Router Solicitation with a SLLAO. Another address, or the unspecified address, may be used, or the RS may be sent without a SLLAO. What the new ND is doing is making a superOptimistic address out of EUI-64 based addresses that would bypass even oDAD's limitations. For addresses for which there is no way to be absolutely sure that there's no dup, it still makes sense to apply oDAD. That will be more efficient if the draft enforces that the routers place the SLLA option in their RAs, because otherwise, the optimistic device has no way to learn the router LLA. Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Erik Nordmark > Sent: Sunday, May 30, 2010 3:14 PM > To: Tetsuya Murakami > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] SLLA option in NS >=20 > On 05/26/10 03:21 PM, Tetsuya Murakami wrote: > > Hi All, > > > > According to the current 6lowpan-nd draft, I have one question. > > > > The draft mentioned NS must include SLLA option in order to inform the > > link-layer address of the host. However when the router receives RS > > message from the host, the router responds RA to the host. At that > > time, the router needs to know the link-layer address of the host in > > order to send out RA to the host. So, I think SLLA option of the host > > must be included in RS instead of NS. >=20 > We should make it clear that the SLLA is required in the RS. > FWIW the ability to omit them in RFC4861 is for the case of sending a RS > before DAD has completed, in which case RFC4861 allows an unspecified > source address in the RS. We don't need that for 6lowpan. >=20 > But we still need SLLA in the NS, since it is the SLLA plus the ARO that are > used to form the registration with the router. >=20 > > According to the current ND draft, after receiving RS message, the > > router sends NS message in order to solve the link layer address of > > the host by using solicited node multicast address. In order to > > eliminate the multicast packet as much as possible, I recommend to > > include SLLA option in RS instead of NS. >=20 > I don't think there is anything in 6lowpan-nd-09 that says that the router > should multicast a NS in this case. (RFC 4861 implementations might do that, > or might instead multicast the RA to all-nodes.) Do you have a pointer to > specific text in 6lowpan-nd-09 that says this, or that isn't sufficiently clear on > never sending multicast NS? >=20 > Erik > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From erik.nordmark@oracle.com Mon May 31 04:29:40 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5340F3A69D6 for <6lowpan@core3.amsl.com>; Mon, 31 May 2010 04:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.94 X-Spam-Level: X-Spam-Status: No, score=-3.94 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XsYsHm4ImvF for <6lowpan@core3.amsl.com>; Mon, 31 May 2010 04:29:39 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 40DF83A67AB for <6lowpan@ietf.org>; Mon, 31 May 2010 04:29:39 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4VBTO1v009863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 May 2010 11:29:26 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4VAV2pj015305; Mon, 31 May 2010 11:29:23 GMT Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 282622451275305308; Mon, 31 May 2010 04:28:28 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 31 May 2010 04:28:28 -0700 Message-ID: <4C039D58.3020303@oracle.com> Date: Mon, 31 May 2010 04:28:24 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Zach Shelby References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090209.4C039D96.0111:SCFMA4539811,ss=1,fgs=0 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-nd: How to detect if short-address is safe to use? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 31 May 2010 11:29:40 -0000 On 05/30/10 01:35 PM, Zach Shelby wrote: > In addition to the current tickets for nd-09, an issue was brought up > on the ZigBee IP list that we should discuss. > > When using a 16-bit IEEE 802.15.4 address generated at random (or > manually) with the nd-09 address registration procedure, how can one > detect if the address was checked for duplicates locally or across > the LoWPAN? In order for a host to safely start using a short address > generated like this it must know that it is unique throughout the > LoWPAN. Then upon failure the host can either generate and try to > register a new address or fall back to using an EUI-64 derived > address. And the ARO with "ok" in 6lowpan-nd-09 means that it has been checked for duplicate AFAIK. > The current draft simply returns either Success or Duplicate Address > codes. The Success code doesn't tell a host if Section 8.2 (or some > other technique) has been used to perform DAD by the 6LR. We think > there is a need to clarify this situation for addresses where a check > for LoWPAN uniqueness is required. DAD may not be performed for > multiple reasons, a 6LBR may not be reachable, Section 8.2 might not > be supported or it may just fail. The intent is that the host shouldn't need to know whether the network is using mesh-under and route-over, nor need to know how DAD is performed in a route-over. When the 6LR returns "ok" in the ARO option it means that the address was not a duplicate and was registered. However, an address can become a duplicate later for instance if a partitioned 6lowpan heals. Thus there can be cases where a ARO with "duplicate" is sent to the host later. I don't see how exposing the host to the innerworkings of multihop DAD makes things any simpler or different for the host. Until an ARO with "ok" is received, the host shouldn't use the address. If an ARO with "duplicate" is received, then the host should not use the address. Erik > I see two possible solutions if we agree this is a problem: > > A. Include a "DAD Required" flag in the ARO message sent by the host. > If the 6LR is not able to perform DAD, then it returns an error code > something like "DAD Unavailable". This DAD Required flag also makes > it easier for the 6LR to determine if an address was assigned by > DHCPv6 already thus not requiring DAD. > > B. Include a new Success code so that there are two, allowing for a > host to determine the extent to which a duplicate check was made. - > Success and address checked for local uniqueness (0) - Success and > address checked for LoWPAN uniqueness (1) > > Thoughts? > > Zach > From matthieu.vial@fr.non.schneider-electric.com Mon May 31 07:51:25 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 721E93A63C9; Mon, 31 May 2010 07:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.758 X-Spam-Level: * X-Spam-Status: No, score=1.758 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAO6zozbQeCm; Mon, 31 May 2010 07:51:23 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id 46B113A677D; Mon, 31 May 2010 07:51:17 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2010053116405474-108776 ; Mon, 31 May 2010 16:40:54 +0200 In-Reply-To: <4C039D58.3020303@oracle.com> To: Erik Nordmark X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Mon, 31 May 2010 16:50:37 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 31/05/2010 16:50:59, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 31/05/2010 16:40:56, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 31/05/2010 16:41:02 Content-type: multipart/related; Boundary="0__=4EBBFDA7DFD8171F8f9e8a93df938690918c4EBBFDA7DFD8171F" Cc: 6lowpan-bounces@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-nd: How to detect if short-address is safe to use? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 31 May 2010 14:51:25 -0000 --0__=4EBBFDA7DFD8171F8f9e8a93df938690918c4EBBFDA7DFD8171F Content-type: multipart/alternative; Boundary="1__=4EBBFDA7DFD8171F8f9e8a93df938690918c4EBBFDA7DFD8171F" --1__=4EBBFDA7DFD8171F8f9e8a93df938690918c4EBBFDA7DFD8171F Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Hi, >I don't see how exposing the host to the innerworkings of multihop DAD= makes things any simpler or different for the host. Until an ARO with "ok" is received, the host shouldn't use the address.= If an ARO with "duplicate" is received, then the host should not use th= e address. But then what a host is supposed to do if an ARO with "duplicate" is received? If I'm right the possibilities are: 1) Register a new short address 2) Register an EUI64 address 3) Stop talking If DAD is available the host can try 1) but if not it should try 2). 3) shall only be used if a global policy within the lowpan prevents fro= m using EUI64 address or if the EUI64 is duplicated (IP spoofing?). Zach's propositions allow the host to run a fall back procedure. As I understand the sequence with B) seems quite complex when DAD is unavailable. - The host registers an IP based on a short address - The 6LR returns only success local uniqueness - The host unregisters the previous address - The host registers an EUI64 based address. - The 6LR still returns only local uniqueness but the EUI64 is supposed= to be unique within the lowpan so the host can use it. So my preference goes to A) as it also provides a solution when a DHCP = is present. Matthieu = Erik Nordmark = = A Envoy=E9 par : Zach Shelby 6lowpan-bounces@i = cc etf.org 6lowpan <6lowpan@ietf.org> = Ob= jet Re: [6lowpan] 6lowpan-nd: How to= 31/05/2010 13:28 detect if short-address is safe = to use? = = = = = = = On 05/30/10 01:35 PM, Zach Shelby wrote: > In addition to the current tickets for nd-09, an issue was brought up= > on the ZigBee IP list that we should discuss. > > When using a 16-bit IEEE 802.15.4 address generated at random (or > manually) with the nd-09 address registration procedure, how can one > detect if the address was checked for duplicates locally or across > the LoWPAN? In order for a host to safely start using a short address= > generated like this it must know that it is unique throughout the > LoWPAN. Then upon failure the host can either generate and try to > register a new address or fall back to using an EUI-64 derived > address. And the ARO with "ok" in 6lowpan-nd-09 means that it has been checked for duplicate AFAIK. > The current draft simply returns either Success or Duplicate Address > codes. The Success code doesn't tell a host if Section 8.2 (or some > other technique) has been used to perform DAD by the 6LR. We think > there is a need to clarify this situation for addresses where a check= > for LoWPAN uniqueness is required. DAD may not be performed for > multiple reasons, a 6LBR may not be reachable, Section 8.2 might not > be supported or it may just fail. The intent is that the host shouldn't need to know whether the network is using mesh-under and route-over, nor need to know how DAD is performed in a route-over. When the 6LR returns "ok" in the ARO option it means that the address was not a duplicate and was registered. However, an address can become a duplicate later for instance if a partitioned 6lowpan heals. Thus there can be cases where a ARO with "duplicate" is sent to the host later. I don't see how exposing the host to the innerworkings of multihop DAD makes things any simpler or different for the host. Until an ARO with "ok" is received, the host shouldn't use the address.= If an ARO with "duplicate" is received, then the host should not use th= e address. Erik > I see two possible solutions if we agree this is a problem: > > A. Include a "DAD Required" flag in the ARO message sent by the host.= > If the 6LR is not able to perform DAD, then it returns an error code > something like "DAD Unavailable". This DAD Required flag also makes > it easier for the 6LR to determine if an address was assigned by > DHCPv6 already thus not requiring DAD. > > B. Include a new Success code so that there are two, allowing for a > host to determine the extent to which a duplicate check was made. - > Success and address checked for local uniqueness (0) - Success and > address checked for LoWPAN uniqueness (1) > > Thoughts? > > Zach > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ = --1__=4EBBFDA7DFD8171F8f9e8a93df938690918c4EBBFDA7DFD8171F Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Hi,

>I don't see how exposing the host to the innerworkings of multi= hop DAD
makes things any simpler or different for the host.
Until an ARO with "ok" is received, the host shouldn't use th= e address.
If an ARO with "duplicate" is received, then the host should = not use the
address.

But then what a host is supposed to do if an ARO with "duplica= te" is received?
If I'm right the possibilities are:
1) Register a new short address
2) Register an EUI64 address
3) Stop talking


If DAD is available the host can try 1) but if not it should try 2)= .
3) shall only be used if a global policy within the lowpan prevents fro= m using EUI64 address or if the EUI64 is duplicated (IP spoofing?).

Zach's propositions allow the host to run a fall back procedure.

As I understand the sequence with B) seems quite complex when DAD i= s unavailable.
- The host registers an IP based on a short address
- The 6LR returns only success local uniqueness
- The host unregisters the previous address
- The host registers an EUI64 based address.
- The 6LR still returns only local uniqueness but the EUI64 is supp= osed to be unique within the lowpan so the host can use it.

So my preference goes to A) as it also provides a solution when a D= HCP is present.

Matthieu

3D"InactiveErik Nordmark <erik.nordm= ark@oracle.com>




=
          Erik Nordmark <erik.nordmark@oracle.com><= /font>
          Envoy=E9 par : 6lowpan-bounces@ietf.org

          31/05/2010 13:28

 =
3D=
A
3D""
Zach Shelby <zach@sensinode.com>
3D=
cc
3D""
6lowpan <6lowpan@ietf.org>
3D=
Objet
3D""
Re: [6lowpan] 6lowpan-nd: How to detect if short-addre= ss is safe to use?
3D=3D""

On 05/30/10 01:35 PM, Zach Shelby wrote:
> In addition to the current tickets for nd-09, an issue was brought= up
> on the ZigBee IP list that we should discuss.
>
> When using a 16-bit IEEE 802.15.4 address generated at random (or<= br> > manually) with the nd-09 address registration procedure, how can o= ne
> detect if the address was checked for duplicates locally or across=
> the LoWPAN? In order for a host to safely start using a short addr= ess
> generated like this it must know that it is unique throughout the<= br> > LoWPAN. Then upon failure the host can either generate and try to<= br> > register a new address or fall back to using an EUI-64 derived
= > address.

And the ARO with "ok" in 6lowpan-nd-09 means that it has been= checked
for duplicate AFAIK.

> The current draft simply returns either Success or Duplicate Addre= ss
> codes. The Success code doesn't tell a host if Section 8.2 (or som= e
> other technique) has been used to perform DAD by the 6LR. We think=
> there is a need to clarify this situation for addresses where a ch= eck
> for LoWPAN uniqueness is required. DAD may not be performed for > multiple reasons, a 6LBR may not be reachable, Section 8.2 might n= ot
> be supported or it may just fail.

The intent is that the host shouldn't need to know whether the network =
is using mesh-under and route-over, nor need to know how DAD is
performed in a route-over.

When the 6LR returns "ok" in the ARO option it means that the= address
was not a duplicate and was registered.

However, an address can become a duplicate later for instance if a
= partitioned 6lowpan heals. Thus there can be cases where a ARO with "duplicate" is sent to the host later.

I don't see how exposing the host to the innerworkings of multihop DAD =
makes things any simpler or different for the host.
Until an ARO with "ok" is received, the host shouldn't use th= e address.
If an ARO with "duplicate" is received, then the host should = not use the
address.

   Erik

> I see two possible solutions if we agree this is a problem:
>
> A. Include a "DAD Required" flag in the ARO message sent= by the host.
> If the 6LR is not able to perform DAD, then it returns an error co= de
> something like "DAD Unavailable". This DAD Required flag= also makes
> it easier for the 6LR to determine if an address was assigned by > DHCPv6 already thus not requiring DAD.
>
> B. Include a new Success code so that there are two, allowing for = a
> host to determine the extent to which a duplicate check was made. = -
> Success and address checked for local uniqueness (0) - Success and=
> address checked for LoWPAN uniqueness (1)
>
> Thoughts?
>
> Zach
>

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
http= s://www.ietf.org/mailman/listinfo/6lowpan

______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= br>
= --1__=4EBBFDA7DFD8171F8f9e8a93df938690918c4EBBFDA7DFD8171F-- --0__=4EBBFDA7DFD8171F8f9e8a93df938690918c4EBBFDA7DFD8171F Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBFDA7DFD8171F8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFDA7DFD8171F8f9e8a93df938690918c4EBBFDA7DFD8171F Content-type: image/gif; name="pic16549.gif" Content-Disposition: inline; filename="pic16549.gif" Content-ID: <2__=4EBBFDA7DFD8171F8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFDA7DFD8171F8f9e8a93df938690918c4EBBFDA7DFD8171F Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=4EBBFDA7DFD8171F8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFDA7DFD8171F8f9e8a93df938690918c4EBBFDA7DFD8171F-- From erik.nordmark@oracle.com Mon May 31 09:57:30 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B933A67A1 for <6lowpan@core3.amsl.com>; Mon, 31 May 2010 09:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.224 X-Spam-Level: X-Spam-Status: No, score=-5.224 tagged_above=-999 required=5 tests=[AWL=1.331, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXfDC0a7nH4p for <6lowpan@core3.amsl.com>; Mon, 31 May 2010 09:57:30 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id F17943A677D for <6lowpan@ietf.org>; Mon, 31 May 2010 09:57:29 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4VGuYM5009796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 May 2010 16:56:36 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4VFxWC8027225; Mon, 31 May 2010 16:56:32 GMT Received: from abhmt008.oracle.com by acsmt353.oracle.com with ESMTP id 311195311275324942; Mon, 31 May 2010 09:55:42 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 31 May 2010 09:55:42 -0700 Message-ID: <4C03AE06.8070609@oracle.com> Date: Mon, 31 May 2010 05:39:34 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> <4C02648A.5060800@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015B3F@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02015B3F@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090203.4C03EA44.0113:SCFMA922111,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] SLLA option in NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 31 May 2010 16:57:30 -0000 On 05/31/10 01:35 AM, Pascal Thubert (pthubert) wrote: > OTOH, > > oDAD (RFC 4429) has it that: > > * Never using an Optimistic Address as the source address of a Router > Solicitation with a SLLAO. Another address, or the unspecified > address, may be used, or the RS may be sent without a SLLAO. > > What the new ND is doing is making a superOptimistic address out of > EUI-64 based addresses that would bypass even oDAD's limitations. > > For addresses for which there is no way to be absolutely sure that > there's no dup, it still makes sense to apply oDAD. I don't see how the additional complexity of oDAD makes anything different in 6lowpans; as I stated in an earlier email I think it is impossible to detect duplicate EUI-64's in a 6lowpan. > That will be more efficient if the draft enforces that the routers place > the SLLA option in their RAs, because otherwise, the optimistic device > has no way to learn the router LLA. Good point - we need to require the inclusion of the SLLA option in RAs. Erik From zach@sensinode.com Mon May 31 13:23:31 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A12A3A68ED for <6lowpan@core3.amsl.com>; Mon, 31 May 2010 13:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+zxziNPuE0R for <6lowpan@core3.amsl.com>; Mon, 31 May 2010 13:23:25 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4BF233A68C3 for <6lowpan@ietf.org>; Mon, 31 May 2010 13:23:23 -0700 (PDT) Received: from [10.24.3.241] ([62.237.32.210]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4VKN01a021848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 May 2010 23:23:01 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C03AE06.8070609@oracle.com> Date: Mon, 31 May 2010 23:23:03 +0300 Content-Transfer-Encoding: 7bit Message-Id: <32546F69-2DA9-4D0E-9C03-CB384C0BFA40@sensinode.com> References: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> <4C02648A.5060800@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015B3F@XMB-AMS-107.cisco.com> <4C03AE06.8070609@oracle.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1078) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] SLLA option in NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 31 May 2010 20:23:32 -0000 On May 31, 2010, at 3:39 PM, Erik Nordmark wrote: >> >> That will be more efficient if the draft enforces that the routers place >> the SLLA option in their RAs, because otherwise, the optimistic device >> has no way to learn the router LLA. > > Good point - we need to require the inclusion of the SLLA option in RAs. Yep, I will add that to the existing ticket about SLLAs. Thanks, Zach -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac@tools.ietf.org Mon May 31 13:24:27 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770023A67ED for <6lowpan@core3.amsl.com>; Mon, 31 May 2010 13:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.012 X-Spam-Level: X-Spam-Status: No, score=-102.012 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFf2tC6KpZ2w for <6lowpan@core3.amsl.com>; Mon, 31 May 2010 13:24:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3CCE23A6403 for <6lowpan@ietf.org>; Mon, 31 May 2010 13:24:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OJBWt-00028A-ID; Mon, 31 May 2010 13:24:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 31 May 2010 20:24:11 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/68#comment:3 Message-ID: <069.f4b85960bba59a4206dd7fcdbc1f0939@tools.ietf.org> References: <060.fe2bdc40f04a8c15333042ebfb94ba7c@tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <060.fe2bdc40f04a8c15333042ebfb94ba7c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #68: SLLA Option in RS and NS messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 20:24:27 -0000 #68: SLLA Option in RS and NS messages --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Comment(by zach@…): One further SLLA requirement from Pascal and Erik: - We need to require the inclusion of the SLLA option in RAs. -- Ticket URL: 6lowpan