From gnawali@cs.stanford.edu Sat May 1 11:25:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A438F3A6965 for ; Sat, 1 May 2010 11:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=-3.186, BAYES_99=3.5, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_16=1.526, 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 uaH-UnDrYXCw for ; Sat, 1 May 2010 11:25:02 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 9E5FA3A69A2 for ; Sat, 1 May 2010 11:24:54 -0700 (PDT) Received: from mail-yx0-f179.google.com ([209.85.210.179]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1O8HMl-0007H5-SU for roll@ietf.org; Sat, 01 May 2010 11:24:40 -0700 Received: by yxe9 with SMTP id 9so246687yxe.29 for ; Sat, 01 May 2010 11:24:39 -0700 (PDT) Received: by 10.150.176.6 with SMTP id y6mr4952915ybe.168.1272738274429; Sat, 01 May 2010 11:24:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.11.9 with HTTP; Sat, 1 May 2010 11:24:14 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01C46916@XMB-AMS-107.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5D01C467E2@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01C46916@XMB-AMS-107.cisco.com> From: Omprakash Gnawali Date: Sat, 1 May 2010 11:24:14 -0700 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: multipart/related; boundary=000e0cd761d8be4ac304858c7808 X-Scan-Signature: 310d485ee50e66a811ea4f775e887272 Cc: ROLL WG Subject: Re: [Roll] Some results on reducing control overhead using Trickle'ssuppression mechanism X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 18:25:03 -0000 --000e0cd761d8be4ac304858c7808 Content-Type: multipart/alternative; boundary=000e0cd761d8be4abe04858c7807 --000e0cd761d8be4abe04858c7807 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Apr 30, 2010 at 9:28 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hi Phil > > > > > > In the image above, there=92s a value (close to K=3D10 in this case) wher= e the > suppression is quasi linear. This looks like a local optimal so it attrac= ts > my curiosity. > > I=92m wondering what the turn of concavity observed there means for the > operation in that network, and which network properties influence that > value. > The network does not have uniform density. On Tutornet, there are more node= s along the hallways of the third floor than in the rooms. Then, not all the rooms have nodes. Depending on the threshold, and depending on the area of the network, CTP suppressed more or less beacons. For example, with k=3D3 o= r 5, there were a number of nodes in the dense part of the network that suppressed a large number of beacons. With a large threshold, there are few nodes with a large number of one-hop neighbors, so there are few nodes that suppressed a large fraction of beacons. In fact, with a large threshold, a significant fraction of the nodes did not suppress beacons. - om_p --000e0cd761d8be4abe04858c7807 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 30, 2010 at 9:28 AM, Pascal Thubert = (pthubert) <pthu= bert@cisco.com> wrote:

Hi Phil

= =A0

=A0

In the image above, there=92s a value (close t= o K=3D10 in this case) where the suppression is quasi linear. This looks li= ke a local optimal so it attracts my curiosity.

I=92m wondering what the turn of concavity observed there means for the = operation in that network, and which network properties influence that valu= e.


The network does not have uniform d= ensity. On Tutornet, there are more nodes along the hallways of the third f= loor than in the rooms. Then, not all the rooms have nodes. Depending on th= e threshold, and depending on the area of the network, CTP suppressed more = or less beacons. For example, with k=3D3 or 5, there were a number of nodes= in the dense part of the network that suppressed a large number of beacons= . With a large threshold, there are few nodes with a large number of one-ho= p neighbors, so there are few nodes that suppressed a large fraction of bea= cons. In fact, with a large threshold, a significant fraction of the nodes = did not suppress beacons.

- om_p

--000e0cd761d8be4abe04858c7807-- --000e0cd761d8be4ac304858c7808 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 0.1 iVBORw0KGgoAAAANSUhEUgAAAWgAAAD8CAIAAADVB6ljAAAAAXNSR0IArs4c6QAANNBJREFUeF7t nT0IN0e1/83/Vg8KuT7gW2KhRkG08SWIkosSULh2WviQNAFR/moK8YX4Uhkr9abSwqhglSZqYUTh EbTQFAnKFbEQQR8lRSSCoEYt0vn/3Hz/9zjO7szO7M7OzO5vtvixu7/ZmTNnZs6ctznnpn/84x/P GdfAwMDAwEAOBv5PTuFRdmBgYGBg4H8wMAjHmAcDAwMD2RgYhCMbZeODgYGBgUE4xhwYGBgYyMbA IBzZKBsfDAwMDAzCMebAwMDAQDYGBuHIRtn4YGBgYGAQjjEHBgYGBrIxMAhHNsrGBwMDAwODcIw5 MDAwMJCNgUE4slE2PhgYGBg4HuF4xzveMYZtYGBgoC0GDkY4vvCFL/zwhz9si7LR+sDAwMBNRzkd +6lPfQqS8bOf/YwxOwrMY3oNDJwVA4chHJCMP//5z/xCQQbhOOt0HP06CgaCogqr9Gtf+xrd+N3v fnfbbbddvXpVu32r641vfOPb3/52flsBMNodGBgYMAwEOY5r165R6Jvf/CY7/POf/3xRDR7b4g5p BeXoIsfxxBNPfO5znxOot95665UrV9qCPVofGOgQA08++eQzzzwDYK9+9as/+tGPZkEY5Di+9a1v vec97xHH8clPfpJ73mRV3bAwVOPRRx9tCEBK09evX08p1rBMOoQ3btxIL1ywR7TLVbDCParaFTNU vhEDv/rVrz72sY89+OCDeX1n9569qOUHP/gBf0Ey+OWeN6HC1d4ngvF/n72qQbWuIcjxug+rfZUO 4W9/+1vNlsoXjTZpN6ub6WjMqlaF6T7Itw+1QLJw8u1vf5tP+M1qPchxvOIVr0Au4OJGfAcCSx5N GqWPjwHGnU5oJsgQzhsuPeqel5jJh39N/dEG+cgBGgJd6AFZ//ymA/Ob3/yGwvpNv4KEAzLJbEDT wdZNdSa5pFfdsCR6Da6GAKQ0LcR2ezEdn376aeYAEEIUdHGPypxLj7rXyyYdQVnev758p4GGcIN2 o93CP48oJV1Ssjguz3ve8yij3/QrSDjo7X8/e4nj4PHzn/98er1tS6IN7V8hKsR2ezH5vvKVr2hZ SiIQGywxUI+6twL1+wIX3D8jvNNAQzjgLFiVWfzFdIxe8pKX8FK/GVeWYHOUwv/17HUUaPuEc4W0 3GdHzgoV9OKrX/3q9t6xUqAXuesl5gAGzyMJCuBginbiuDKIXHLRBx54gLL33Xdf8heXWFC2bXrO FEQy5cY8+qEaDD2bOYO+04Z5iRh/VugDn+bfYHKW3B2yHqmEgfNWJfXcfvvtDF86G4I95d577/3y l7/8oQ99KH1QgoQDqsE0oieAAuHAAexA0sogHCkzgC1BugmmsuaZ9J2SR7hJn3wpzY0yYIDVxAXC hWcjyqsf3TFiNCH3rNkscv/II4+8+93vxqryrne9K2OMQqwOXZJFk7r4hSnizXa+qE4NQ1RJwTNm PBgN15iX8tUoswUDrKMi8sUsDDAaK0y/60SVoHIUEigHMF1GIzNo0ijaNwYYU1RrQxLpdpRkIpEV nBuxhJFHV9hJ71RhqwrzieMq1jz3/auv05E1SmoW3nTTTSNMQbeTgRXHutMAyS5uhCP0qJMiWdc6 q0qQ44DdADjRDn65P5ByNAtxo/DAQDUMZDmeaLfWupPSAA5RXhGhR73Pugo7gMk+jIYWIPiVxTgL oFF4YGBgYAsG0HQqmkSkEvEgijix7ubXv/419ec6gLU/frJF1RT6diflKPjNOgWwR9dGnYfGQJZy VJxF/BJNMfvrupsVE/tgoQO30O8m36LTIpoJqgTs2R/4wAfc3YO/eMklvVf9a4V7cn0gL7NFpgSX fPDi15/+9CeKIQEhEKy7kVUl+/LoWfz7JfLXy/+dcBzyquKXESWUiWIRCUe8RHzlJRc3jHp93A1z bH2cJ3IcOu2RAp4mWErJUJl1LsK+A5jp2NGGIjXJXKetiUnfPJBPIl3cyQEMxkGsIIyDfC55jBib xEqYbkiemlJfwYYw3tJ74bcDtlnGib2bLaagivwlIzo123FVgJSjlyKqWAFUV3yV5WW4BcLzfSus yt3T4uPFH3W4ZtGzznMkjaCOOclE2qJ/1LTMnQa+qEKXdIlqMP/k1sr9gQL57DpHE6mGSIaNqE5A a1bpRKO5yXDjnXFcAb/sdnFFmletZvCwsq/ANp/kHkJVK4pWsdgiUyVxubEPbaEai5AEC4QYGD6A v7B/xWts4YhqfrufqCKJgwvZMrFHJqnaV3rjfi7mJbHC2WKSddOh2tLW+FbC5sYhK4JGZk4TUSWo HGUvgn+WCz2/3C/yV+up13G+RMHpcQdyo5pe1ifoBTMM4ZY38tvZ41rBcewBRld1aqRksLSwQ6Ue d+2plKO7NrGx8uAhN0QVFolJblJwHIWt3U/HIakNDcWKI38wnzj2sc/oCCPcgfDJmse2gjJsS0wa 6TiAbUslGydTb59LKDDRwA7yCc7tj/ttpek6ju04X6fjWJA+mM3sloc7B7WfqCLuVFKl7kM2M/6C LrgnmrjnjRhU9y/3/Wr2dZ1ufHVzh/iwE2liBa76t6os+HHIgjjOQXl0nRkJWsRMmoXVmx/8hdaT MujeIer8cm9u+9wo3AmX+377BjJqOAEG0pWjzTobJ4eKXp1oUl5BWXf6ZG+OA7BlPY3rpRBG5K9B SYivW1h/adRzlVvSmLj2M0XxG2fkvenUIcfBcEuxqkGPP+60Orxq1/GqQVGFme2KcNwfSGO/E+Go M5CLrTDbIBNQLsiHpmCr7ASLoLYt0JWULXc7xbgBMMm5Ih+hxxTsrdh4ihCOoKgi/2hpN/jlnjfN +KLR8L9iAC5GkZbkKmIhvAaeOseA2Ey5SnEjZVnosee+BK0q2Bcxo5iTklkEeu6MwbaTVaWTvuPn x7j0GeVA5oBEN8osn8sVhVEeSRvVcOAUzk/Ou9iGTXTdDpLsaDqlsqW2dVaVcchtC87bfNt8MYS6 zRRM9HesgzjIa1uqIW7CbAss9ayMJylYos42SW1CchRIh5iZqMK9ckEe4jq3jqMr0d2dDwCWq+g9 xHTaAuR+6qft2g31a51yNMhxyLlAR8L5ld9BCgkcZfbGgCUx2Luh9PrNm7b5Dp8O88aS8isTE2EB /qaPOsG4sa0OPw8SDiiFDLH2exS30Q6xXBYkeU+XrXNjbSwPdOede0lv7KP3OZomBkJ+OtALnUWe PvIy5CK4ER6YhY3ajS0AxHQcFrZMBDXlVN8WUMa3x8UAjAbCLDzp5XAckAOFiUdLreNIDN/s407D iijQkFIHCQcwcZ7Csg1bzuE9sABJMpkoRJ5E1HWWzAultQdIPdcpd68OIbzAYzJ0WZnZRDFnHzsc qe0gBQmHcj56aqHt7U1rgOvm6BeaV9YDv9xP+XCFwJD0hJEYIrIiDPwewK+uE7osIsiNmF47XysG 2KjkbIHeRJXVeDjuh801TW1FlZgfh+vUvN8Ay6/MNK/eo9p1Y2dNH6ew9e/HYdn62KmUbNGMakq/ 6KobvQINJdvQNDBvhf3myajZw8D22F/u4spe7CFTE1N5v1x1bqNwet4R0mmuSZ1AF1fiBe+chb9/ c+x+VrottsPV30q7sfrzI35YbYGEkMOyL2L8XmeODXIcbPJs/kDmHo3dQ/VlgTxnmQujsnJd1SNE hIUXsfL0yXFIvpBNBOFLyYEPtJHCVoSSJEsz1SErVBa9GjudbJab/wkOjq/zHA0ecpulEXvsDAyt Dvy47iheQ2xoLDMd0oVkKBJqBBg4jjvvvNMOgO0Bdm6d0mh6R1pzK2lYXlnHhVK5rnLZo8wKDcGr 07Q6TlvepK3T+lThuJHj0CHJu+66a0V32ocRjUS7MUwpk4A9IrnQ1chh/w5FFZ1uajLDijSaHlqm SHMdViJa2Q9gbUWV9mdVGAw7EwUuuJ9ldrwM2GVZ0FGbhwGwzWU6Wj1eOJbcmPU9oAIS1lA2/Lf7 77+/LRbgJj7ykY8888wzgIEU/aUvfemLX/yiREf5t3CvrNfcU0zWyltuuSUC+WOPPUbhO+64o23X 3NZZhAB/zz339ANSCBJAfeihh/hXuUu5rly5otNrF+ipYVj63ve+99RTT/WDAZSDzKjtakcNNzMz T1/TA+sl+Vk0whVJXGbM1LTK3x2PKtShqBI5ACa1dg8DIRhk8QHD3Oji/kBhnHbCpIXt2qn+3Grb iiodzddcxMWVo9COghVurypif11BONyghFBSV0kmV2hR4XUKy3HIdftwH6iGdeZYX8cB/yPTGjf9 M9UHghApzHIybgdbh6mgF4w6gq4iIVNtihuu27qiOSiLBzd2bYfwfDXseupiBbr6OqvC9mXn2Sx1 jd2s6N74JAsDrGTltY9/pQMBsg4qgKB0QPziJscj7/nlPnKmW6lzplpPnd3KAvsSCvemHG2Mc4+n igfdOAoD1qGOI2KONVEFk6c0OLl4Vq4svkpxw7XKR7b6LDwnJprPqrOHwutElaDnqNKCNaZqa5vv 0HNUps1ZHbhc96AaCiaaGzBJ4olYjEQ3XOGVD8W55KnT1w7K0b+TMNh8UYj9Z9Q4UM5uBDwax9Xo heXk82JnVXqghath6JDjiJzmEMmHZdDpbOv17FRw9Z1yonWVo3yy6IY7OI7V86qHD8W6as5YdoXV VMM+zNWjLziAKWev66C1HcTLrIFdPe4CwNaBxOHG+52dpsazoLwgYIqO7dg2yKN74p77yIkethqL 1XSZg5LV606Uozojow3GZX9yV747u9785jfn+oMECYdCYMAO8auIPsN3MGueeYWhCPHYkzqAg6hi CkuL0OHeyOYlI4hMKi5pSHTD3dKRi/22E+Xo4g5UZ4BGQqYkPFvcHfmtWtwdxeCRkkLLO1QgkWuT gkMkJsJxQDUgMRbS0QxhUB+ZVwWGVBihHkJxYIJGKNkQfhhNZfaVHZ3tM3EQk6ZUZiFNMI1sD9GP g4QDlJmzpo5FdpUyIxPtW4uLPxRCdJhafoSsXu65uNGbeIFFOFjGsq2Ks5i9+Es++NPAjgoSwUjx F7/IPrks6CKEl1OA0ZTWSWnJpFxodWmC2aHkVmD8s92QvocSrvc396E9sAeNkQdDceXoKZ0phzm2 w6kbAini8L7OnurpOHJREeQ45DskTRu/8ixqT+caQSA+olHjezU7lKNxzO7tmilnYi4F4l68aSgo TRE1EjIlLcuyDuNJTY5CrTHgmS2Kg5PlPqMkDMVhWF9hnEWxhEy5nEzb8sVFlaOH4ZkdjiGqxGep jgLtN5NLBWrtS1QRKYLIwaL3RerWE8nsLy2136FN0RJJdFlsnj0SIGfjt6cPptkb9x50OUn1hIMM WNpHAMsAtnpRCZ9S9IiuH/FSGhrvCCyPPVj1+sHnNHujpVnaCUjZ6XaqfPdq9+PEGtZcSlQxJhCu vmF3NjZN8A64YvqC4GmxeUYMUcOqRhkruEIWSTwRrjZiPv75mUWV3enWQRrI0mN12Ce5GypBoS49 dghqfZAUol2H/bxkjrsCc1pRBRbXC8mxKx47rFxT6ugLTJqavSX2DocvBBJ2VjmDyvGXeY7UVh8/ hxZVukg63e2cG0uu26HZAhgyiJySzPG3yd4Ax9GVa0YWStsnnc4Ct3Lh4SJVGeF1mrMAaxJPFPGs vjR6TlGFNXPJrqKawd1yHAoOaoJk/JFDK3DF4zCbUSXpeuoQqUgr5xRV6JUb2aE5lgcAhgHF7OAy wrH4OLDnYkDHFJvj5NCiSjA9gqLsy4xn167WqYKVlzLH9ulbyXDsbSksOBYdVgXJ2Jh1tUinSrkj 9+U5qhNuSIPu2e3mRLoyAH3qOGA0BjO4ZSbsfQglEbZziiqzXvqJGDlNMcXd6IGtPQ1Ke+gIe+GW 6L6lunBoUWXEHI1NA7mcH9dmVmqKn6yeuHJU4d0qdPm0VpVqMUcZKoKbMlr8Ro79ID1ZsUsOR9aJ bq/C0tqpieIIZGvxAsQql0L8OqeoopC5UsLxy/1ierElRM3/n5i1EKrBpZPObkTfdY2Ory4ZA8VF FUWTd80IkVCvhvlDiypBqwrdqxM6EBS7ucu8R1Nfy8STqM0uZVXRkafeErXvHSciEclnLWaJ9XTU LSW3nqKB5iLknFaVajsSsonr8Mv9VFpRFAlAkqjCIfE6Jwu6dQCrNjqnbCiR45CGKyW3HvOEy+To FDkFxJ5TVKkWcxSK4JotuJ/aGvUGTbiyFkm6qTCn+zTHVuj4oZvQiT6NHR1R0in3McVzNJ1q0IQ2 NpOjkalTaMc5RRX4czc8L/c7cezgfTFrobhHAwCdC4+wkSHmEFHlzjvvVGDoLb5S211rctnXlPLD ASyOJeiCHBclPvAr7YP7GKlBg56VkdMbEZnwF4eyuagClrRGXvOa1yxC6xUI6jhUrkLMUUbIVV5w r8Tr7mWjbi89cuOVL6XjGIQjdz71UJ4NRpe2Fn6nj4uEQ6TH0/Ql9s7VksQbKuLAun2WkgIysWtW bMGPo0LM0ZSshZRxI0pICVLBL6tPB7DhORqXpBBjsdYrTx0lla3Oe1yUxdIzciIEIZi48jUDlDI5 Dy2q+ITD1qcXwseSDC5iPLdAJGuhEt6pQmizspNxYRhWJIXctnLL96DjkCZPEUOFkDqK4Vxc9VNe No4i8KRk5IQkMShQK51XVuxSNx20B4nSiYrWHDdYsS+qmAgwi/dcfiaxPMMjKsCvawMWvVAlcJtm G+cmrnApJar0YI4FIVzmI6CgoYmIvcxiG3VAnqAh2jF7AsPQq8mpwAUwOO4c9oZARE1qVK7jiioL Oo6DzrxShGO79LgdgSOqcC4OlUA396s65ZX8tWxb22dpSR2H564PW3X16tUi7N+oJAsDyoeS9cmF F2YhpThuNsESInbZ+FiIPE2OX/g6DsldEr1cNQdi2xCtm0y10WguBhL9u3KrLVLeXBmL1EYl+Iw0 OenrEw5LhAtMbiQO4CulcCqFsgr1nCPKeQVEddVEQeVo8X7twT9KUVJ5efqEA22wBDBXbSNNpESp i7raupzL31E5UC4K7emdlRBn23j/RoqCosp+hs4U/Af9OGT+1EgwPCg4LlDSbmuO1e7URIJNmTo9 lJHtU5d45IbcewpCCooqEghSGt2jTCyvivnMSBW807H6PXpVqs6GHIeUTfJAGxxHaEClaNSJam7E FGNS6VY5WlZUoZutNMELeVUspj4gXiDHUYoAbamngp/bFvDafiuSodwoQCI53x7bwjbbekFRhfqV sLLJDIm5nLtmlMs0qTRxOYdAy1W0wrzfEiYPCJvvJW3Z9RUDtF1Ucc0XKwAo9UmQcEDIsaSY8on7 btm/UriY1lNfx8HEklJD20i39Ho232piCMiC4yX/y4IV7l3VdlHFHNVb8RpCUZBwYF6BEbr99tsV CpT7iPv93uhuVX8TjkMsN9jm6lC7AV1jn2dieIOSGAKy7FCaWrRstfvVVkpUEcVsuJffhJ01giZx VqYl3Q+hZWt+4IEHqPC+++7bWC1bKItEh/o3VjX93OVaxV/wBhZD2K6TsVEd1BxQ6BqoVXw6Gtge ZqQ718kOLu+xOPZUoYwpDddPbr8kgU734HTJlGFi1OLLNheqt7zlLY8//njeV2Xd5jup7RBnVTiE wv7DpHePPOl+p5hJ09GxA10Krpl1xIN55h798oLC6uBiJ/OhHzBCZ1XyFu1zCh8xK3lWxesJO+E4 q5I7uvHyLFSJQuw/mk8ST7ipw24YeOI1gGTL1p0SArIsAqntcMrRiKiSdVK2OCZzK4yZY91UEZdJ NXZ1OZctrTKNmJ0f8iNyFbFelhA9duiXeTjlaNyqssXIlbvyN5YPEg7MKFBHIgto8Vym43NZBzAL xqN90oxWG4dw++fidFx4Znn7uKIHCuhGwZJqbDtsqsE4C9EvMClix2OTI17p/VLYHruUHmhKl9Mr 9ErCLcqCwVUz62CQcDDwMK4KtKXQIx1uOKvRnfhhQXOssCeRRPyqbgqursROTYvJjQp4TEW3guPg c9etg/uCGmXompxEFQdYqNPj6l7X/FAxgbn+89nLHt2bFehifkIsFP6K3Z25xGMlE35IbwRapfpS 3JHE+KudaKE6VI6WCvdUFsPusCp2fLp+1GaIQFJVUu5qPcejZmV1BKjSAcuqee/CQoW1IkoRatQd jhR1NWVYnq4qfR3aSypHkVDME4ndkg2kh72xwi4hNlinp5p7RlborzUhTS0dX7dlMYNZ2/Ly4Jc9 MHcL9c6quY/bHS5rYtJt6xe/+AWPUj/L1zZlUiWaxqVGsIWJEERbdTzQY6djRTjgCdXnLSr3VsO2 ol13aCVZFKGYYrBXwLPrJ2InrQkkAravxP5OY0AwQyzZcG6cq3jodmlhdkXFTpX/5S9/cWtOcepb YeRihSoAsoXv3ak7/6w2hVVjNkSyH6XUULnMFlFlJ64YHBZk3Svjs0JzYlgqNFS5ibvuussVVeKt S1RRMgdXopmlAu50Uv4jiDU8yIoOlhRVXA3tEU0qN27csEgnYnT16AZ9mS2wjlFfJPDHjoW/2L3N Bdo6UG8Gv2QFK4xcyn8E5ZVfaUloAnXFTsemCGMVQFzXhHuIUNKyTHqu5GxGPrcAhONChLJ1iN3p Kw3NTpU3rPaJJ57IbT3dyIVSg3NkufUXKR88qwLd4riBrF/WUodS+iwWOKsCxyExG5jlX6BfS+Bi hHlaYA/1kribgwrqRaZavBJFLdoD8xWAjzRx9913P/zww4lHS9yjQ0xXiEI8KJHK6OACG56Uo4gt uV0ueVZllkasEJ+afLJFx7ETwEPHsSjenzLR1Aodh2u7RdkRP7gkF01RCijIulNOJXUcs5q8XEo2 yg8MJGKA3bKOcJ4IT6liWaLKCiMXxMIMFxCRRIvY9t75Og47kuAlZNre0oXXMJSj8QlwVuXoy172 slPOfJ9wKIOuaL9u3OuUKBid6gEDZ1WO9oDbPWCYyasC06gTRDI6uNceEIhCoeNRqLFFfhXd++CG dhqIvauVPy6tWK52e9Thnb0BKFi/zvXo4GLkJktUKQje7lWFVFZZ0QG2KBRRicndRWccuI8oyeTA D1LiLQ7l6JYR2e9bHaWTiUHD7T7u1+4eNdMFC3dmRpPpzQc/+MHF6boHeFl1llSOVjMc6vy+Atjo EKSsStMLg9O1a9eqAbY7zb68BhhcLTa5qzOUdqzrWOyGhg69ldankYbpzc0333zKcY45gNXpMLKJ G5KX+5C0gtDEVDuWqV+OqjqevyiF1UF4w1bOpMjwtLlThaDe7OSI3HAQ1fRCsOIK8KGwcKMBuz4w but4oynSeqiAWxgHsOvXr7/pTW/ipRL2VOjIbBMSgNlONY1WOOe0gny0G8cA81ZhH///Qrrppkj5 RAewyjhHwSSvyO9+97u//OUvs1o/BuGgh6w6zNT0LZFwUHJ7lPMsVE4Li2pAuaSXKRvbZiNsTT6H 45CbY5PWyzY6JRwKfDXbSueC2ArP0ZiowryXsQNc7HeOICXkHAf8uSw+2v9wSs8eIi47FXaqDX5H 5x07nz07dd+tFjm0IfdXtoNTxxMN8exVtukeaoslnUZJaY5oZnYqDjSIXgw5Jy2aLjGHh/AXOuXh i5QJYGGQZNe3RwT+0xCOM+lrUsbUKxMkHOzwsF4mk7NcFden+EUrSpWKDKIZZqysXtKiTg3rkiaV m9NMweIobVghMrN8NGZhGO6zDYemcNMhe692dTM17Rpz1MIWKeyqgQQMU3eSFEg68ePYKSZQlom+ cmFFwTxW2Kd1KGIeug5Hs3N1Xc31v1rhxxFUjqLdkFcF2gR6AruBXYOzd4Xp1j7VlUoBuRG6UL6/ jdWOzytjAEZpquNDkGe9ve1tbxMwPLpGlsoQbmxuhXI06IIJFhAKRCn45b6aL+l2itsJxxEPab29 mx3WIH7wZEES1anF60ALxJs5KziOWLZ6eE4lJedXfn6LuBsFXAxcoHJ019x3bWeXRw09UYWleFEL JGaOBREWtPqikNJ2gh669bK573pGxbCqzI9OSDHe81gO2JpgwE3IiC4M4/px/ayVZ8C77LC4nBLk Q3ThRr0gx4FyFG3ooeMVN1lFbqPHTSOUiDqM5fIPtISM3MDDu4ePEqvqp5gSU7kXJ1yJx0P0UDkE 6FAvJrOL9ugLKdgwi1qw38MlvBjK0Tp6U7TmkIl1cS7rQJjbikiD99UpNb5uH0sqR5WqnjnBDbYo GJCjuHi33btkumMrdoOqtwVpY+sadx3S48Z9PJlGI+S6Jl/yauE8N45Xnc8XjtWDLPw4xX2EwmTU AfRArUAyEPX5BXs7udtWwIYSEfKrcTfC4T7SQR5Pow4L9YVuInwNwvEvsy7Cy2FSsVSXYkByGb9W 5RuKKqdxnTyfGLI4G1kYs74YQ1SZoi7IcRBrC/EErlvJGkzlUWGvG020woCFHTp3zKFQ0J0Q2oeo MsVMkHCALLm4KA5oq6l8uHYPzdayT8iUhpCC/uKsZrVpFG5LBjo73w49pjutIJ9wWLAzmVQ82rwT EKPaTjCgw8fy/tSBw0MbViNYRXNngRrcm9kgQzBiZ1LllJlsnvRCpXYodtrAopTYSYGGOg7xaAfN ZngheSpDuozQ7D2N3irUwRXm2PahA8vQv3+tpebpWNh7bctylpOF0pTKe/RuvzqxR7K19hkgc0Wv 5fE5vRig0ElWMMA4KlIZFjG7kVfYWb1FV5yODeo4vKRHcGtXr15dMXjn/gSq4VmppRs6KIcPvTsN 1ZCgPWsqjkSBCgUNVaj6c0/mrN75HId5SUOt3dPEjMGB9qJqHId0QKc5AQgdZJtNPEWeNc+aFPbi CafAcJkhVFZwHD7hELM6i2Lo9FGm1E6EQ1TVdQmV2fIchIO+QDWUgyJlje1XxpzNUpr48Y9/TDEC 6kxvFGvn8ccfN3KweCN58yjzPAU/KWUKEA5rBhQ3n0ApfZ4tswfhkGqddaW5JWEE9pVd+gTsvagG fexhzUR2rxVTgtGR3J1ygx6U1ntAwoqerv5kBeGIBfJZDcdZP5QDvgVbh7Dq+N8J+otkKu1MP31J sdDNnkmbGgr1RrQjfiNTdD9I6BaS1BSQbK1DOdrtKG4HjOV0XAZze/dHDbkYCBIOOHA3nMnFUg3J 24rgcugQNd7MgMWwfvEX47tfzq30Sak4OunHKSF2g96lo7dgySDhUBJ5+Q7Kj/CgJsYtyFIeEPoO Sywh5TRIYHDpnVh9UNQ2w647RhZHJ2Xg9ssTltL6RZcJSZIgRS6kzDB+EeZNREwRPtuWKeU5emg3 0LZDsK71FJ2FW3Nu+XVQnf6rFZ6jyzoO+b2c1WfuEjYNJCyJIfKk5J4rfqyrDlp0ms69ckNVDlGl zkhNWwkSDnhyBaGBZMCuM6IXeEb2HOepdc7VOykv21Craad2pwHEdMQuHaohqqTjqnDJEBuGdoNl w782vQ6Ub6aUqHKBwWxqsuXbA+QMUaXIeJUUVRS/ByrF2CDq4xizn/qazZCgQajT+Q2FkIH9IS+U DD0EGaoTru64MTVlAOLiJp4IuvBGFK3Oi9KQK5hM6x6iSs3hc9vyXc7joZ/2iAfPtIYioNWnclpH /IZIeSoVykBToGUUYzHIXEexENZKeY4q8nA/Fof0WYLiAA6R8uAKxTaPPYTz905OqjvwHavnlbQ2 zWWu9HHps+QKz1GfcMwOrfV2Dy9JxG/ql9WGy3vUS0RZOA4YHz2KjkQm3IUTDpaTcv0KV9yzt0OL m2upmF1QYe8E6pY4wINwFKFEKwhHMOl0EdkppRImtJu3hXvexD+UDAXHESp24ToOxXxMQX7lMoxa WU0ZcyAyDSr37rjNldRxFKFkKZWwJbqCCfdx/QWiCgyIgtxF6r9+/bpU7nW0ISk9rVMGcQ+urU6v aWuaMDHypggGLAkjNwi5I93PaqwihmuN/PWvf82tJBgBbCqz7HSsnoZcoYO5CP8ZkokUOAeSAWMS YbwvWVSRXsZcQnMnRFZ5DRbSR7oQtBEwxYVhAkgtIr/e2UChWR258MIlRRU3gqtW6U55VajZE1Vk BvYuOFJNF/mzxq9SosrhPEel11hCT7H/t9tTc0Gp3MFc8A5avqSoop1BFxQdu9dOPCH1u2Y57qc6 dsQTdjYlNF6tgT/frmJ2Vlmj1EFTIe/aX7G4e+SpE/8sjfj0hukh2jGuxhhIpJHaWxILZxVTzcwG bjQnjKfQS2pTnFiXCeI+kuu4FMfRuQMYNEJoUf50yXcpHFnWAM0Wdmdt2Ra1MZisOnuzHf5Rg4uB FRxHkBZ4q5ThXDR2rB4MWVKYLsrlYfWIoPA4y2VE5uuFEI7VCN/+oQ3N9qqmMukwlBTHarzCkoTD Y4Q8TUTljuU2V4pwaDPv07QJTuqrGKY0PWtotBvBx0EaQjcgvKzJNgvCyyy8gnAED7l5GGSwL0p3 LWdzrp7j4ks8OZDSRwdh0VOgvAjd8O92V/TG8v8FNL98rP4CkDDTRREO1LE9p+Hp5xBK4iSRzgjr GLr2yM1+p6IS4RzFFjEQIxwQfu9U0mJ1pymg42F0Z4tD9GmwUaojBChkRimHM4xS6CbrZH0p2EY9 WRgIEg655XlxVrKqPnThPQyN2xGiGDyKf0Nt3KNOrhxjSUGApn0RVIrMGrrZjoFRQycYiMUcneqo OgF6bzDkqC5eeu+2cutvTtEUh1VWNgPedSSJ9Gh67jm3+6N8LxgIqZGBr6x9vqa+eqNVxfxHasJ8 lLZmfTeHQ+dRhm8WzhVWleBZFeQUnVtNP4bQCy18znNWn1XR2YdqZz1yMbZHblfqzDoRJ82X+WWp C9KFDaVm7oB2Ur7kWZVZx96jkNXVHId4jW5ZLTxKisO2zprrzQQ5vBxlegw4PQys4DhiCZl0osy9 OiGQO4Fh2aTXraWdoKpQrfxBsi4PKh1arQDqaKITDAQJB/ZInYBwr06Avlgwul2fTJJx9uyipmUs PUKW6HtcrBEQhMg3WFJk6dy1I7QlWyY3UAE5UKY/YlKRm/mWy4u+E48yu6Wh8e2JMfBv999/f6h7 TGs0hU899RQURFdll4HVeH/sscf49o477kip4Zlnnnnta1+L5ZXecb+rx9c999xz5coVmqAheUDd csstuY8pnYqUYRwfeughRYf+j/+9NhqeFWApMpc2wjw+3xUDX//619///vfnNRGSbGfl/CwxuGHh LOUoe3i1Y2xg1Y1a1ARFexyNG8rRJkNZqtGSytFZ7X0eTeq7tA5ZcbFVVhPKxNe0Qowko8SATHIA tSyN8ZuhGW01pq3avdxDbqxh0QtOslUzo3gOl5VHXYQyMa+lnQ9OBHJv9VAiGKNYJQxEPEc9CFYY 7UqxUrn1pIgqTdxDQWlDfwcZyBKRuYdEk9j0KFYZA4VFFfPgkP/omeJxSNe7nTZrW6YeZVpcfNwv k6Zlq5RnJ48/+tGP8KB95JFHHnzwQd38/ve/52C7Dv6qTOSGEe/ztM72URs1FMBAIm1LyZOUWFWF YoscB0sife+NAKxtmQJyZFh83C+QmjEIErt4fMMb3jA7P9R3lUm5qTBeo4m2GFjBcQTPqnhzLp7u pAABK1rF4lkVneYkvumWZtEdsmlzQIPlJ90Bl6K0Rx53OgivsFo6LQJUaHAefvjhe++99zOf+cyL XvSiv//976961auwrPPvXXfdJeZIWp7FmyMeVtoyrBf47YqzKkHC4fkFyfRQJ/T+9pFLIRwnO5Ql ucN1QhGtN7ZiO1ZHDWfFwArCEbSqeCF8mJSn8SlmZ2aZzW6kCjahJccs4Tf+aNlMZqcUn8tVVFkL c2/uvvvu9ASLBNeifn7tk9lwO2ed+qNflTGQKqpUBmtjcxGOA9KAgzlEcJbjYIXDW8FY8S/KYJ2v B5jQI39FdMZQW5zEJZvowH7WzdNPP/2JT3zirW99K96lTzzxxL8/e8VvXve61918880u9gCvoefI xnEcn9fBwAqOY5lwhDbnOl1a10qccEAO6iwnuVqtjlIxZI11oz++ysXACsIxI6qwSRLFx9pmB4YB jvPkuYBWKK9s9TTkZhKE+Wc1fuMb3xBlmSYZfOc73/nyl7989q/ZjISRZIWKvpnrFqWTb/slWKyA +dHERWDAswPJ0OCaKnE9wLeSlzslnd7DEIU5VoNH5d6N+jL7Fybn0F/TelLegLpco+9UkVQ8cs8e CB91HhoDK8yxPscBZ6HczkY1UdRDMnh5LKYD2qG1rRHVDf2yRJbeXyqjE2izf7n1JJYBdetOwbuz sJo7/EXsk6OThTDg6zjQyYtMePUjv1y7ds222UKt51WjkBl8g4YirjhAEvn+97//3ve+949//ONz n/vcF77whT/5yU84O//LZ68Pf/jDP//5z1//+tf/4Q9/oLYXv/jF9sh9HkylS4Nn+tgWz6X7NOrr HQMrdBx+0mm6OMsbm09kK5YMHh4DKkSNixsIRwSSz372s72PVRS+Vkj22q0WbWB1f/Gg51r9eZ0P +0cjm2guKnyO47bbbmOJTk2MbINs+AxSqwXpAqawMRFvNAyuP/3pTz/+8Y97HAePL3jBC1wWw+M4 /va3v+FhWaePRE953/veN9tWJ+KJuaLWQciKVuSm2Am6QvD3j8aXvvSlTz75ZB7+PUoDyUAyn5If XvJXLlkqVV40wvYW0a8IIQfUhtAm9rrhMdnTQKhzmIndaVWs/4G+9dZbc5Hjcxx4bbC3Ky2wwskp QC5mxYZpuKYnZdDFRJyp4TgeffRRXKeAH6QQrS+PmlYpjcEY62+VplY20j+EN27coG+vfOUrV/aw ymfdohEugxCW4OA73/mO9H3pl29VQX3ATo7pAVcOOS/Lc7kh1UjvjJX89Kc/LarR89U51QB1/UMI yeicahwCjStOkwQ9R7tK1w6/AyFDQtEBE2DDJw1atjHEbs9kZcA2MNAzBoKH3BRgTpG4m3dAhz4t 3zI3PA6q0XxcBgAXi4HDxBxF2Yl2GpLBxc2ZwpFd7OQbHT8uBpYPuXXSN8QTdLSKpo1ItvrkWCfd GWAMDBwaA4chHIfG8gB+YOBkGDiMqHIyvI/uDAwcGgODcBx6+AbwAwNtMDAIRxu8j1YHBg6NgUE4 Dj18A/iBgWIYwP6QHqf2tIQDky1OYlyJqVKLoT9QUQo8lMHfH29dgc1A7g2VWz9+/WqdXy/G/RQM zhlSsiZ4tJUIIQZ760j9pLaLA82wciTC3LJzY8Tth3NwtTju/2w993DLIcpnncGv0KMUeBR/TFmd lDqv5uEozhmoReWd18mDEGbw2ZVbYAXUWROJECrqAghURwCy5im4lIHGqVLBsQCMwDdA2zwyAGBY ROvEMa069okwbS8GFhTLi6uHHHQp8DCf3BO9oiPbUZFYg3eeOHK8mFmu7tQEj14kQuiiOrHvBYul DLRHyyqTttnO6pCxfKMSsZFaLrG6HorlnsHfG+Z18Gjn3Bs2q99bbxFqa7tl+iQr0osUCIVqUKf9 k9/KXBuNLgZ/8DgOPukk0k9WsK4T6jiUTdqO2OimSIrpdeLlCnj4BIGzpls9LbrpV7ifxRjCOfN+ GllyHWayvkqBUDArb44EAQWgympodeHEgVY8cAJxoolEHQOoR0x8c0LCsXrge/gQzRkTnaPArM/e 3OpZhMqV2wOiIjDALkFzhUBu7GxkJ2AzvnBt4jLQFimNcSewpYNxQsJhR++FBdkmGp7xTYdH5gAA Zj5VXp8A6bIY3E8xphOGbpQW7qvt5ykQasRdhgjyUY3ZTBlobCiQCQZXXAYUBI6jGg7T6cJiyRMS jt7O4CfCw84Djw0fK/3C4siVLcACc+2C3E8DeTLdpUUzRRo31eSpFAgVBcLdwJV5syyuQrUlDrRt Zu7GVgfCkq0UUVz1VolnFaupIZtFRQgemQz1iXQHtjIrR9OUYszMsdybFVMvvX5lKdKKTI8IhC4a hWrROJljayYSSxlo6AuXDMbAWdnuHhmLrDE9oVUF1KDZtmhozalGBB4BqbGc3Q2KLLnESozTYYt2 F5sISnPCAQAhCF00UkyrF7C9jiTiYUux0MRzIaQMbJpB2MP8VJezCMc4Vl+SfRt1DQxcCAZOqOO4 kJEb3RwYaIiBQTgaIn80PTBwVAwMwnHUkRtwDww0xMAgHA2RP5oeGDgqBgbhOOrIDbgHBhpiYBCO hsgfTQ8MHBUDg3AcdeQG3AMDDTEwCEdD5I+mBwaOioFBOI46cgPugYGGGBiEoyHyR9MDA0fFwCAc Rx25AffAQEMMnJNwcJhaYSO8qyyiqTwjKnS47VL1lO3dhdemKXREJNSB/JyEQ+PtHVHX4b+Nlzsq iv6wscLx+cDAETFwZsLBwvausiMEJSKwQtk6R20DA4fAwJkJx+wAECEWroFfMaLKjkMCJCUicoO4 uXl99J5fpbrSt66IQdQpN5eSNa3miEyrNEuh/EBE3BJIXiqmKQyqOQK2QQI8Fm7TTQJEfy3Vk9rl lyinXiomazoENl+pX1x8bgHEXLS4DJqLeTdRlocidwjsE8swNosQFxJAst6FuhDCKqOjQXS7482i WUwCAF+5IdSoATzr29nmvHnothIZlNA0UxI2jaCX4SnU2cXxXaBfW8KWdPutpBJPVFHcet4rar6i WhFSReFeLGAU8T55r1DUbkQsgjV5wU7UhFfYy6VEGUt0pFiYqt+9NEJuKiYlWBEMCgvGPdyTBX1J B9vrJvXAJVkCFyFKmQf0l3IyKM+AQFL00ynYfAVIQrJ9KAxbxDA3NoyLCgW2Ue4b9/0UexosGxRL zqCQhUKIQaIugLFIF7yMTRaAy02IZVGgpjPcMO9h0k3FIOzFYfbmodtQaFDcOekhylIu6D2Vq0Lv EwMyZXzjq/ucEcBm1RmazTbbhBdFcDMc2aRXFFl7z+LRo7cS9K1XWKNldMqtx11UbqPTVEx8rhhz VkyZkLLAplo6yIe0a0G9XPCMwqpa651uLEUIj9NsY26d/GtojBAOFxXApt5Rfrb708GivAsGj0KI CwlLQis21AWRHsOqshNoEF0wvKhiKh/BpOIPq5h7H4E5FPsrNCihaeZB5UI+/URApozv5RKO2Z5P ly7zjNUFuhWe1+iLS1CsqlnCMa0zVE+IcHhtqZg4Ee8ySNLBdmHW5waG95f7CDa0QYVidmpzY3tn nbj8SIRwuN20trKwN4sQRe5k2XPjJjea7UIIqx4YU6R524aHSZfLYLmKPxWqZ2GenQn6JDQoIURF BjEyhRbHN044Lk7H4aFSagtF0DcGdRbdrV564ycwKoDNdBRvguSPxD7tPguV1QLhQMBWeqEKKJrO Zg0ckLASgARQTUsS6sJ0S9gOOUQWeoHigLmElsFN0TAL8/YWE2sIdXZxfBfqj9OVg/47u114W4Q9 2o4qlm9W+lBqH283CBX2RJVZUchFLPXMZo2Vycbjq7Wjuu8jYLOigHxRVJnyU3AQ7tY9uz268osL g1vYi8a8QlRxsedJGRIzXSmJjgj53IS64HHv1CBVy0ZRhRpAtXgNKVl0zcKsEZxlaSMcxzpRxZ1a 4ERDkDK+8bV/Zh3HbM+9AWOjMO2ju1BDiiiRJHHmVlVEa+U1NztdRNpNE2nqOlVrudeVUlydSgFb i1Z0x1XpiatXPSEu11W+Sg05zW+qPdayrlsZ6ue9FqRymhiNtm66sLndnypH3dWlf71M9JIR3EEU lkJdCA3WVB1ukLsTKYRJygiSaY7bKczrCEdkmmluKClPXDmqoU8Z30E4/gUD3tKFBGhya7mKw9Rk ZRjcv1QLk8MWg1uVLRIvTUYi4Qh9LtW9lhaw2eqNgG1ZwtwZrJD8qocbV+vpLg+jIxQwZtvbMw2b wGBJm9wyVCIU8asyRjiATZ/wl6sFsPdx7FGPdJmqwVX36qWwJLIe6YKLIpcJctMvyMgyXTwhTKqk a12yb2dh9iaG21BEZxGaJ9ZZESkXcnca29CnjG+ccIz0CJpv49odA3gZsCSmCeJC73cHaDSwAQOX rhzdgLrx6cDA5WJgEI7LHfvR84GB1RgYhGM16saHeRhATjF9jftl6H1e7aN0XQwMHUddfI/WBgZO gYH/B/2+gF+Tv5kXAAAAAElFTkSuQmCC --000e0cd761d8be4ac304858c7808-- From gnawali@cs.stanford.edu Sat May 1 11:40:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7B63A6A47 for ; Sat, 1 May 2010 11:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=-1.786, BAYES_99=3.5, FM_FORGED_GMAIL=0.622, 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 COh-dGYULBex for ; Sat, 1 May 2010 11:40:24 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 0709C3A6A2C for ; Sat, 1 May 2010 11:40:24 -0700 (PDT) Received: from mail-yx0-f179.google.com ([209.85.210.179]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1O8Hbl-00087N-Kr for roll@ietf.org; Sat, 01 May 2010 11:40:10 -0700 Received: by yxe9 with SMTP id 9so250244yxe.29 for ; Sat, 01 May 2010 11:40:08 -0700 (PDT) Received: by 10.150.175.12 with SMTP id x12mr5359308ybe.195.1272739208480; Sat, 01 May 2010 11:40:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.11.9 with HTTP; Sat, 1 May 2010 11:39:48 -0700 (PDT) In-Reply-To: References: From: Omprakash Gnawali Date: Sat, 1 May 2010 11:39:48 -0700 Message-ID: To: Matteo Paris Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: b0d2d5ababd8fe43140185de29a9e1cb Cc: ROLL WG Subject: Re: [Roll] Some results on reducing control overhead using Trickle's suppression mechanism X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 18:40:25 -0000 On Fri, Apr 30, 2010 at 8:27 AM, Matteo Paris wrote: > > Hi Om, thanks for this work. =A0I have some questions. > > The two graphs seem to use different data sets. =A0For example, looking a= t the > left bar graph for motelab for k =3D 10, it looks like about 10% suppress= ion > as compared with k =3D infinity. =A0But looking at the CDF plot, it looks= like > 50% suppression for k =3D 10. =A0The tutornet data does not fit either, a= nd the > CDF graph does not indicate whether it is Motelab or Tutornet data. =A0Th= e CDF > graph counts "beacons suppressed", whereas the bar graph counts "control > packets sent". Are there control packets that are not beacons? =A0I would= like > to see both graphs for the same data set. Recall that beacon suppression mechanism does not suppress beacons that are sent due to nodes requesting routes (PULL bit in CTP) and datapath inconsitency. So, although we suppressed 50% of the would-be beacons, that does not necessarily transate to 50% reduction in control overhead. This explains the apparent discrepancy between the two plots. Sorry, I should have included this in the explanation. The CDF on the right is for Tutornet. I have noted this on the page now. > To get a true picture of the impact of beacon suppression on delivery > ratios, the experiment must be done on many different networks with > different densities and topologies. =A0In particular, networks with nonun= iform > density have a higher risk that beacon suppression will partition them. = =A0We > can't conclude from only two data points that "beacon suppression can be > used to reduce control overhead without any negative impact on routing > performance". As I explained in my earlier email, this network has non-uniform density. I found that suppression mechanism suppresses beacons to different extent depending on the density. If we pick a threshold that is not too aggressive, it does not partition the sparse parts of the network (because it does not suppress the beacons) while reducing control overhead on the denser parts of the network. It is hard to vary the physical density on the testbeds. I did another series of experiment to at least emulate change in density -- run experiments with different transmit power but the same redundancy threshold of 10. These are presented as the second set of results on this page: http://stuff.stanford.edu/~om_p/ctp/beaconsuppression.html We can see that the suppression becomes more impactful at higher density. At lower density, it does not suppress many beacons, which is exactly what we want. - om_p From pthubert@cisco.com Sun May 2 23:46:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0B43A68EA for ; Sun, 2 May 2010 23:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.692 X-Spam-Level: X-Spam-Status: No, score=-7.692 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_50=0.001, 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 24WIlxTGggw4 for ; Sun, 2 May 2010 23:46:32 -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 608E43A67FE for ; Sun, 2 May 2010 23:46:32 -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: Ag0FAFMN3kurR7H+/2dsb2JhbACBPpticaBLmFmFEgSJTg X-IronPort-AV: E=Sophos;i="4.52,317,1270425600"; d="scan'208,217";a="191468697" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 03 May 2010 06:46:18 +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 o436jo5u003907 for ; Mon, 3 May 2010 06:46:17 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, 3 May 2010 08:45:28 +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_01CAEA8C.3790CC03" Date: Mon, 3 May 2010 08:45:25 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01CD834D@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: closing on #27: DAO ACK ? Thread-Index: AcrqjDVFfQuRH0M5RUCH+Ry3bJ8qbw== From: "Pascal Thubert (pthubert)" To: "ROLL WG" X-OriginalArrivalTime: 03 May 2010 06:45:28.0351 (UTC) FILETIME=[37A742F0:01CAEA8C] Subject: [Roll] closing on #27: DAO ACK ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 06:46:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAEA8C.3790CC03 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: =20 As you know, the main problem addressed by ticket 27 is the delay caused by loss of DAO. I've seen a few voices with a general support for the mechanism, but not enough to declare a consensus IMHO. =20 At this point what we can do is: =20 1) Reject; no ack for the time being 2) Adopt, all nodes need to support it. DAO ack request would be an optional flag in the DAO. 3) Make it optional controlled by the root so a node can only join a network as a router if it can ACK DAOs. =20 Please give us a feeling of the WG intention here by voting 1, 2 or 3 this week! =20 Thanks for this, =20 Pascal =20 From: JP Vasseur [mailto:jpv@cisco.com]=20 Sent: Thursday, April 15, 2010 1:57 PM To: Pascal Thubert (pthubert) Subject: Fwd: [roll] #27: DAO ACK ? =20 Salut, =20 Can you try to close on this one ? =20 Merci ! =20 JP. =20 Begin forwarded message: From: "roll issue tracker" Date: March 10, 2010 1:33:38 PM CEST To: pthubert@cisco.com, jpv@cisco.com Cc: roll@ietf.org Subject: [roll] #27: DAO ACK ? Reply-To: roll@ietf.org =20 #27: DAO ACK ? --------------------------------+--------------------------------------- ---- Reporter: jpv@... | Owner: pthubert@... =20 Type: task | Status: new =20 Priority: major | Milestone: =20 Component: rpl | Version: =20 Severity: Active WG Document | Keywords: =20 --------------------------------+--------------------------------------- ---- WG: RPL 07 provides means for a node to advertise some reachability using a DAO mechanism. The DAO can be triggered by the node to match its own needs. It can also be stimulated by a parent, by incrementing the DTSN, or by the root, by setting the T bit that causes the DTSN increment to span the whole DODAG. The DTSN was added as a replacement to a single bit because, due to the nature of an LLN, we thought that the bit might be lost whereas a DTSN increment must be seen at some point. But the other way around, the DAO message is not acknowledged so a node might not obtain the service that it expects, and a route propagation might be inappropriately delayed. So the simple question is, should we make the DAO a bit more reliable by adding an ack? Pascal. --=20 Ticket URL: roll =20 ------_=_NextPart_001_01CAEA8C.3790CC03 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

As you know, the main problem addressed by ticket 27 is the delay = caused by loss of DAO.

I’ve seen a few voices with a general support for the = mechanism, but not enough to declare a consensus = IMHO.

 

At this point what we can do is:

 

1)      = Reject; no ack for the time being

2)      = Adopt, all nodes need to support it. DAO ack request would be an = optional flag in the DAO.

3)      = Make it optional controlled by the root so a node can only join a = network as a router if it can ACK DAOs.

 

Please give us a feeling of the WG intention here by voting 1, 2 or 3 = this week!

 

Thanks for this,

 

Pascal

 

From:= JP Vasseur = [mailto:jpv@cisco.com]
Sent: Thursday, April 15, 2010 1:57 = PM
To: Pascal Thubert (pthubert)
Subject: Fwd: = [roll] #27: DAO ACK ?

 

Salut,

 

Can you try to close on this one = ?

 

Merci !

 

JP.

 

Begin = forwarded message:



From: "rol= l issue tracker" <trac@tools.ietf.org>

Date: March = 10, 2010 1:33:38 PM CEST

To: pthubert@cisco.com, jpv@cisco.com

Cc: roll@ietf.org

Subject: [roll] = #27: DAO ACK ?

Reply-To: roll@ietf.org

 

#27: DAO ACK = ?
--------------------------------+-----------------------------------= --------
Reporter:  jpv@… =             &= nbsp; |       Owner: =  pthubert@… =        
    Typ= e:  task =             &= nbsp;  |      Status:  new =             &= nbsp; 
Priority:  major =             &= nbsp; |   Milestone: =             &= nbsp;      
Component:  rpl =             &= nbsp;   |     Version: =             &= nbsp;      
Severity:  Active WG = Document  |    Keywords: =             &= nbsp;      
----------------------------= ----+-------------------------------------------
WG:

RPL 07 = provides means for a node to advertise some reachability using a
DAO = mechanism. The DAO can be triggered by the node to match its = own
needs. It can also be stimulated by a parent, by incrementing the = DTSN, or
by the root, by setting the T bit that causes the DTSN = increment to span
the whole DODAG.

The DTSN was added as a = replacement to a single bit because, due to the
nature of an LLN, we = thought that the bit might be lost whereas a DTSN
increment must be = seen at some point. But the other way around, the DAO
message is not = acknowledged so a node might not obtain the service that it
expects, = and a route propagation might be inappropriately delayed.

So the = simple question is, should we make the DAO a bit more reliable = by
adding an ack?

Pascal.

--
Ticket URL: <http://svn.tool= s.ietf.org/wg/roll/trac/ticket/27>
roll <http://tools.ietf.org/wg/roll/>

 

------_=_NextPart_001_01CAEA8C.3790CC03-- From dat@exegin.com Mon May 3 11:50:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139893A6886 for ; Mon, 3 May 2010 11:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=-0.555, 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 Bgr154gRa2Vd for ; Mon, 3 May 2010 11:50:40 -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 228373A685D for ; Mon, 3 May 2010 11:50:40 -0700 (PDT) Received: by pvg2 with SMTP id 2so577689pvg.31 for ; Mon, 03 May 2010 11:50:23 -0700 (PDT) Received: by 10.140.88.9 with SMTP id l9mr3694521rvb.286.1272912623443; Mon, 03 May 2010 11:50:23 -0700 (PDT) Received: from [172.16.1.52] (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id h11sm1638442rvm.9.2010.05.03.11.50.21 (version=SSLv3 cipher=RC4-MD5); Mon, 03 May 2010 11:50:22 -0700 (PDT) Message-ID: <4BDF1AE9.1070206@exegin.com> Date: Mon, 03 May 2010 11:50:17 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: 'ROLL WG' References: <6A2A459175DABE4BB11DE2026AA50A5D01B50F5B@XMB-AMS-107.cisco.com> <01f601cae64e$23853350$6a8f99f0$@alexander@ekasystems.com> In-Reply-To: <01f601cae64e$23853350$6a8f99f0$@alexander@ekasystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] DAO fan out X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 18:50:41 -0000 Hi Roger First, let me just say that I think this is an elegant solution to the fan-out problem. I just have one question: What does a bit-map for the Path Control field offer over just a straight forward decremented counter field? I realise bits can be merged at a common parent, but since a parent would need to wait a nominal time to receive multiple DAO's, anyway, I can't see why a simpler counter filed could not be used instead. Regards Dario Roger Alexander wrote: > Hi Pascal, > > Please find attached an expanded note on the DAO fan out control and path > prioritization mechanism. > > Roger > > From roger.alexander@ekasystems.com Tue May 4 15:49:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA4228C29D for ; Tue, 4 May 2010 15:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.334 X-Spam-Level: *** X-Spam-Status: No, score=3.334 tagged_above=-999 required=5 tests=[BAYES_95=3, 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 m0-sJaxz1jCU for ; Tue, 4 May 2010 15:49:17 -0700 (PDT) Received: from web1212.biz.mail.gq1.yahoo.com (web1212.biz.mail.gq1.yahoo.com [67.195.14.59]) by core3.amsl.com (Postfix) with SMTP id 2337528C600 for ; Tue, 4 May 2010 15:08:18 -0700 (PDT) Received: (qmail 90340 invoked by uid 60001); 4 May 2010 22:08:04 -0000 Message-ID: <803054.88370.qm@web1212.biz.mail.gq1.yahoo.com> X-YMail-OSG: .PVHn8MVM1kAZJQLSZP_m_4cCX.h0JmFpa5gcX.MOOS.XKE ao_8KjwetqyIF4qHH6kAbXkozWExRDBIB2a8oEtxiTD1Ez7X3mM7GwNkXjiu NQ_x83Xb0MNar9E3ExgKdOY.arA_CExguYKFAQ..c1nzVMhISfxEGiVUwdC4 LpiKHiJfCjSMRZ1XDwF1OOakMsThPJfVQCuM_1xkfvYShmGqUJFqGyzl9gFJ BaY.PJP_Y6aiSwqq92fV8qCKcYN4CWKoXEJ9US.LhmA1rcQmDpAtMHnZ4OhJ C3jKMmGp9D02lbKat14Nge6fYy._DkulAh0Eh04cEn0i3QZZcrAKW Received: from [12.188.45.3] by web1212.biz.mail.gq1.yahoo.com via HTTP; Tue, 04 May 2010 15:08:04 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.100.260964 References: <6A2A459175DABE4BB11DE2026AA50A5D01B50F5B@XMB-AMS-107.cisco.com> <01f601cae64e$23853350$6a8f99f0$@alexander@ekasystems.com> <4BDF1AE9.1070206@exegin.com> Date: Tue, 4 May 2010 15:08:04 -0700 (PDT) From: Roger Alexander To: Dario Tedeschi , ROLL WG In-Reply-To: <4BDF1AE9.1070206@exegin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Roll] DAO fan out X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 22:49:18 -0000 Hi Dario, In the case of storing nodes, the destination address received in a DAO message at a common (storing) ancestor will have a route entry validity period associated with it (currently communicated through Prefix Lifetime). In that case when a new DAO message is received the updated Path Control field can be immediately communicated in the relayed message. The updated Path Control information will reflect the combined validity of any DAOs received to that point. The benefit of the bit map is that it will allow identification of preference in addition to controlling the fan out count. The preferred path can be used for purposes of prioritization when multiple downward paths exist at the root node (or other intermediate common ancestor). The root or other storing common ancestor will be able to distinguish downward paths based on the particular Path Control bits that were set in the received DAO messages. In the case of non-storing nodes, under Richard's current proposal, the node owner of a particular DAO message destination address will be able to indicate the preference ordering of DAO Parents using the Path Control bits. Each DAO message sent to the root will indicate the selected DAO Parents and the preference ordering. For non-storing nodes the only common ancestor that stores DAO messages is the root which will recursive calculate the downward path(s) to the target node based on the preference of selected DAO Parents. Roger > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of Dario Tedeschi > Sent: Monday, May 03, 2010 2:50 PM > To: 'ROLL WG' > Subject: Re: [Roll] DAO fan out > > Hi Roger > > First, let me just say that I think this is an elegant solution to the > fan-out problem. I just have one question: What does a bit-map for > the Path Control field offer over just a straight forward decremented > counter field? I realise bits can be merged at a common parent, but > since a parent would need to wait a nominal time to receive multiple > DAO's, anyway, I can't see why a simpler counter filed could not be > used instead. > > Regards > Dario > > Roger Alexander wrote: > > Hi Pascal, > > > > Please find attached an expanded note on the DAO fan out control and > path > > prioritization mechanism. > > > > Roger > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mdurvy@cisco.com Wed May 5 07:28:05 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 alexandru.petrescu@gmail.com Wed May 5 09:36:40 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55D073A699C for ; Wed, 5 May 2010 09:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[AWL=-1.539, BAYES_50=0.001, HELO_EQ_FR=0.35, J_BACKHAIR_11=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 dgpNop-u9Ifa for ; Wed, 5 May 2010 09:36:39 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id F30053A69D8 for ; Wed, 5 May 2010 09:36:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o45GaMwI015491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 5 May 2010 18:36:22 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o45GaLv4027994 for ; Wed, 5 May 2010 18:36:22 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o45GaLQG024235 for ; Wed, 5 May 2010 18:36:21 +0200 Message-ID: <4BE19E85.30801@gmail.com> Date: Wed, 05 May 2010 18:36:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: <8739yc279m.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <8739yc279m.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] RPL ticket #32: Asymmetric Links X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 16:36:40 -0000 Le 30/04/2010 19:13, Richard Kelsey a écrit : > > Note 1: This ticket is not concerned with asymmetric links in > general, but specifically with how path metrics are constructed from > asymmetric link metrics. > > Note 2: The ticket is against the RPL draft, but this is really an > issue for the routing metrics draft. > > > The problem: > > An asymmetric link metric can be used to create a number of > different path metrics, depending on how the upward and downward link > metrics are incorporated into the path metric. The resulting path > metric might reflect: - the metric for messages travelling upward - > the metric for messages travelling downwards - average of the upward > and downward metrics - best of the upward and downward metrics - > worst of the upward and downward metrics and so on. > > Rather than try to encode all of the possible combining functions, > we can allow the inclusion of both the upward and downward path > metrics. > > A useful example here is latency in a network where nodes wake up to > receive messages on a fixed schedule. If nodes A and B wake up to > receive once a minute, with A waking up 5 seconds before B, then the > A->B link has a latency of 5 seconds while B->A takes 55 seconds. > If A chooses B as a parent when building a DODAG that uses latency as > a metric, what value should it use for the latency of the A<->B > link? > > > Proposal: > > Add a flag to Routing Metric/Constraint to indicate whether the path > metric represents the upward (flag = 0) or downward (flag = 1) > metric. The flag would only be meaningful for path metrics that are > aggregations of potentially asymmetric link metrics, such as latency > or link quality, Hmmm... yes. On a related point - I am wondering whether links could be asymmetric for energy consumption (as some are for bandwidth or MTU). Until now we know a node must spend a certain amount of energy to send a packet on a particular link. Would its IP neighbor spend the same amount to send same packet? I guess yes, in this sense energy metrics would all be symmetric. On another hand, it may be possible that a node spends amount X of energy to send a packet but spends amount Y to receive same packet. In this sense, its energy link metric would be asymmetric. I am not sure how asymmetricity would fit energy metrics. Alex > > A single DAG Metric Container would be allowed contain two Routing > Metric/Constraints of the same type, one containing the upward path > metric and the other having the downward. > > -Richard Kelsey _______________________________________________ Roll > mailing list Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Wed May 5 10:28:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] RPL aware hosts (Re: [6lowpan] how does a node get an IP address) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IPaddress X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: zach.shelby@sensinode.com, roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 richard.kelsey@ember.com Thu May 6 05:46:39 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB9B3A6B67 for ; Thu, 6 May 2010 05:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=-0.606, 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 Vsx6-RqLoJOG for ; Thu, 6 May 2010 05:46:38 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 16FB53A681F for ; Thu, 6 May 2010 05:46:02 -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:49:08 -0400 Date: Thu, 06 May 2010 08:39:34 -0400 Message-Id: <87y6fxyzjt.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D01CD834D@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <6A2A459175DABE4BB11DE2026AA50A5D01CD834D@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 06 May 2010 12:49:08.0101 (UTC) FILETIME=[847A2350:01CAED1A] Cc: roll@ietf.org Subject: Re: [Roll] closing on #27: DAO ACK ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 12:46:39 -0000 > Date: Mon, 3 May 2010 08:45:25 +0200 > From: "Pascal Thubert (pthubert)" > > As you know, the main problem addressed by ticket 27 is the delay caused > by loss of DAO. > > I've seen a few voices with a general support for the mechanism, but not > enough to declare a consensus IMHO. > > At this point what we can do is: > > 1) Reject; no ack for the time being > > 2) Adopt, all nodes need to support it. DAO ack request would be an > optional flag in the DAO. > > 3) Make it optional controlled by the root so a node can only join > a network as a router if it can ACK DAOs. > > Please give us a feeling of the WG intention here by voting 1, 2 or 3 > this week! I think we need a way to ACK DAOs (these are lossy networks, after all) but I am not sure that we need an explicit DAO ACK. Without local DAO caches ACKs are crucial, because indivicual DAOs travel multiple hops. Any source-routed message serves as a DAO ACK. Even if the most recent DAO has been lost, such a message shows that the root has a working downward path. With local DAO caches, individual DAOs travel only one hop, making them more reliable. On the other hand, receiving a downward message does not function as a DAO ACK, because it does not show that the parent has the complete current DAO. My preference would be a variant of 2): - Without DAO caches, treat downward source-routed messages as DAO ACKs. DAOs should be retried at some low rate until an ACK is heard. - With DAO caches, have an explicit DAO ACK that is required. In the interests of simplicity, I would make sending a DAO ACK required, with no ACK request flag in the DAO. If no one else votes, do I win? -Richard Kelsey From mcr@sandelman.ca Thu May 6 08:50:51 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157A83A6D0F for ; Thu, 6 May 2010 08:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.645 X-Spam-Level: ** X-Spam-Status: No, score=2.645 tagged_above=-999 required=5 tests=[BAYES_80=2, HOST_MISMATCH_NET=0.311, 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 Z+TuctZV8tdl for ; Thu, 6 May 2010 08:50:49 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 1D41228C28A for ; Thu, 6 May 2010 08:37:19 -0700 (PDT) Received: from sandelman.ottawa.on.ca (ottawa-hs-64-26-128-5.s-ip.magma.ca [64.26.128.5]) by relay.sandelman.ca (Postfix) with ESMTPS id 6C4BE34A9E for ; Thu, 6 May 2010 11:37:06 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 060F14E7D3 for ; Thu, 6 May 2010 11:37:04 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 06 May 2010 11:37:04 -0400 Message-ID: <10172.1273160224@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] host only nodes in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 15:50:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pascal and a few other people asked about host only systems in an RPL network. Consider an industrial application. There is some piece of machinery. I'm going to pick some cool hydralic forklift. Maybe it's a robot (no operator). It has several dozen sensors and actuators, linked together by some kind of fibre-optic LAN because of noise issues. (Maybe this new Intel optical connect). Those sensors are going to be interogated by a management system. There are two network architectures I can see: 1) the forklift has a single interface node, it runs RPL on the wireless interface, and normal IPv6 on the internal sensor network. Either routing(%) or application-layer gateway occurs. 2) the forklift has one or more interface nodes, it runs RPL on one interface, and implements (layer-2) a network bridge to the other interface. In case 1, we can use all sorts of network routing protocols to make the subnet for the forklift reachable on the RPL network. A grounded RPL uplink node can do things as simple as: route add -net 2001:fork:lift:gate::/64 2001:fork:lift::host In case 2, we don't do this. There are many reasons perhaps why we might not do this --- perhaps the sensors in the forklift must interact a lot with a lot of devices that are nearby. In case 2, do those nodes speak RPL, or does the edge router(s) do RA/RS? (I don't have an answer. I think that layer-2 bridging like case 2 is IPv4 think, and routing is a better choice) - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS+LiH4CLcPvd0N1lAQKLZQgAgB7EJ6MYbDa5ch2qQLvw5IF7RPhspMSv T/V64GHOyC9YXceO6hBHDpGguqvnv5d4VcHr2fJ95WAaNidscHec4Rk/qNzViBd7 Ob/76m8JUey4HLd6f7ZE/1+pYR2JlX0p72unOISrKtug6Ka/NlXyF7yEv5EAbAZD gK4gLzK+L8ijqPwRx3/VHbyRFQ3xesLiVUdVBq+MS12EbnwVYvdhYeoWFfFQw80G L1JcnNJgiKtkOllFKOXcT+DeRxUy3b7AeOdbbZlnWV5bdfjUjNTTU6jnpFV12MGq wJcVul7naea3jHB8TjlhtjAINe2XEGvUCCSOX2TKTnxynp572bC2hw== =OpTS -----END PGP SIGNATURE----- From behcetsarikaya@yahoo.com Wed May 5 09:23:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED0983A6C3C for ; Wed, 5 May 2010 09:23:46 -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 oc8kAVRm4BBK for ; Wed, 5 May 2010 09:23:45 -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 9AD7F28C0E6 for ; 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 X-Mailman-Approved-At: Thu, 06 May 2010 09:47:57 -0700 Cc: roll@ietf.org, zach.shelby@sensinode.com, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Routing Over Low power and Lossy networks 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 roger.alexander@ekasystems.com Thu May 6 10:06:05 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58333A692E for ; Thu, 6 May 2010 10:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.835 X-Spam-Level: * X-Spam-Status: No, score=1.835 tagged_above=-999 required=5 tests=[AWL=1.500, 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 dMmKBmMscCID for ; Thu, 6 May 2010 10:06:04 -0700 (PDT) Received: from web1206.biz.mail.gq1.yahoo.com (web1206.biz.mail.gq1.yahoo.com [67.195.14.53]) by core3.amsl.com (Postfix) with SMTP id CA5873A692D for ; Thu, 6 May 2010 10:06:01 -0700 (PDT) Received: (qmail 45816 invoked by uid 60001); 6 May 2010 17:05:44 -0000 Message-ID: <731069.44982.qm@web1206.biz.mail.gq1.yahoo.com> X-YMail-OSG: bMVhf3kVM1koWPd3heWo9urfxLmhT12aMwkXYfi2G8YgdKu .sQy2.WMWK5GE1fbBBR1LedQPztSehALT2LSfViD9XDlswAoN6LgFC4hOvLh 5TTLE1FGWe88Lc5RF3OqcZ12YTKmNGqhk2Q5iRLpHbGlDQKMcsvhD5O2ff_M 2K5FOavD.ASE3mEFsOgGfXi8oV.vQI3iby86C6S4Aa52kd8mPtYZ9JRjIptD UZdqNUDG6r0gVHF2B.E3GQIc1wOgmaVN0DmyUzEqUJ9jwnnDKtz8p9wMNsVf KH51jS2UQVw8P3cqEDAoGdPj1tp3AlCcW_QwQWW5rMFIJiSyb04Q0lqKucDM DKOYjbR0ccPdhJ1lmwdGZHv.V0oX3NA-- Received: from [12.188.45.3] by web1206.biz.mail.gq1.yahoo.com via HTTP; Thu, 06 May 2010 10:05:44 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.100.260964 References: <6A2A459175DABE4BB11DE2026AA50A5D01CD834D@XMB-AMS-107.cisco.com> <87y6fxyzjt.fsf@kelsey-ws.hq.ember.com> Date: Thu, 6 May 2010 10:05:44 -0700 (PDT) From: Roger Alexander To: Richard Kelsey , "Pascal Thubert \(pthubert\)" In-Reply-To: <87y6fxyzjt.fsf@kelsey-ws.hq.ember.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: roll@ietf.org Subject: Re: [Roll] closing on #27: DAO ACK ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 17:06:05 -0000 Hi Richard, I think your vote should be considered a win. Roger ----- Original Message ---- From: Richard Kelsey To: Pascal Thubert (pthubert) Cc: roll@ietf.org Sent: Thu, May 6, 2010 8:39:34 AM Subject: Re: [Roll] closing on #27: DAO ACK ? > Date: Mon, 3 May 2010 08:45:25 +0200 > From: "Pascal Thubert (pthubert)" > > As you know, the main problem addressed by ticket 27 is the delay caused > by loss of DAO. > > I've seen a few voices with a general support for the mechanism, but not > enough to declare a consensus IMHO. > > At this point what we can do is: > > 1) Reject; no ack for the time being > > 2) Adopt, all nodes need to support it. DAO ack request would be an > optional flag in the DAO. > > 3) Make it optional controlled by the root so a node can only join > a network as a router if it can ACK DAOs. > > Please give us a feeling of the WG intention here by voting 1, 2 or 3 > this week! I think we need a way to ACK DAOs (these are lossy networks, after all) but I am not sure that we need an explicit DAO ACK. [RA] These are lossy networks that can have reliable link layer transfers. Nonetheless, what is considered from the perspective of the RPL protocol is an acknowledgment between the routing (control) entities. In the case of the DAO, this acknowledgment can serve the purpose of confirming the downward routing state between RPL entities. It is in this regard that I favor an explicit DAO ACK. Without local DAO caches ACKs are crucial, because indivicual DAOs travel multiple hops. Any source-routed message serves as a DAO ACK. Even if the most recent DAO has been lost, such a message shows that the root has a working downward path. [RA] Without local DAO caches the communicating (control) RPL entities are the originating node and the root. However, a DAO Parent(s) has to be participating on behalf of a node to ensure that a downward route can be derived to the node. Without DAO ACKs the RPL exchanges between these participating entities (node, DAO Parent(s), root) are all implicit. With local DAO caches, individual DAOs travel only one hop, making them more reliable. On the other hand, receiving a downward message does not function as a DAO ACK, because it does not show that the parent has the complete current DAO. [RA] Agreed. In the case of caching nodes the communicating RPL entities are the node and its DAO Parent(s). In this case the model should be one of explicitly acknowledged DAO exchanges. My preference would be a variant of 2): - Without DAO caches, treat downward source-routed messages as DAO ACKs. DAOs should be retried at some low rate until an ACK is heard. - With DAO caches, have an explicit DAO ACK that is required. In the interests of simplicity, I would make sending a DAO ACK required, with no ACK request flag in the DAO. [RA] In the interest of simplicity and compactness I do favor requiring the DAO to be explicitly ACKed without a flag. I support Richard's suggestion of tying the capability to the caching/non-caching mode of operation. If no one else votes, do I win? -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From robert.cragie@gridmerge.com Thu May 6 10:39:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: ROLL WG , 6lowpan@ietf.org, zach.shelby@sensinode.com Subject: Re: [Roll] [6lowpan] how does a node get an IPaddress X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] So do we need instance ID selection in hosts? (Re: how does a node get an IP address) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 alexandru.petrescu@gmail.com Thu May 6 11:02:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A203A6B3B for ; Thu, 6 May 2010 11:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_50=0.001, HELO_EQ_FR=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 caQJv1oC6lBC for ; Thu, 6 May 2010 11:02:29 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 2608C3A6BE8 for ; Thu, 6 May 2010 11:02:27 -0700 (PDT) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 2B37794007C for ; Thu, 6 May 2010 20:02:11 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP for ; Thu, 6 May 2010 20:02:10 +0200 (CEST) Message-ID: <4BE3041F.7030400@gmail.com> Date: Thu, 06 May 2010 20:02:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: <10172.1273160224@marajade.sandelman.ca> In-Reply-To: <10172.1273160224@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100506-1, 06/05/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] host only nodes in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 18:02:30 -0000 Forklift RoLLing around ____| / | |-----|____ O O Le 06/05/2010 17:37, Michael Richardson a écrit : > Pascal and a few other people asked about host only systems in an RPL > network. > > Consider an industrial application. There is some piece of machinery. > I'm going to pick some cool hydralic forklift. Maybe it's a robot (no > operator). It has several dozen sensors and actuators, linked together > by some kind of fibre-optic LAN because of noise issues. (Maybe this new > Intel optical connect). Those sensors are going to be interogated by a > management system. > > There are two network architectures I can see: > 1) the forklift has a single interface node, it runs RPL > on the wireless interface, and normal IPv6 on the internal > sensor network. Either routing(%) or application-layer gateway > occurs. (exception - stepping back from the assumption RPL must be run here) If I were presented to such a deployment, and knowing the forklift moves within a limited area (a hangar?) then I'd immediately think the egress interface of that forklift is WiFi - a single subnet - no change in IP address nor routes. If the area is larger (maybe a few ARs each 50meter range, with less than 10 subnets) then I would first try an existing routing protocol like OSPF or simpler RIP on the MR, but not on the devices on the forklift. If even larger area (route updates provoking too much "churn" - numerous route updates, large routing tables) then use Mobile IP tunnels and NEMO extensions for moving networks, still on that MR, still not on the devices. > 2) the forklift has one or more interface nodes, it runs RPL > on one interface, and implements (layer-2) a network bridge to > the other interface. > > In case 1, we can use all sorts of network routing protocols to make the > subnet for the forklift reachable on the RPL network. A grounded RPL > uplink node can do things as simple as: > route add -net 2001:fork:lift:gate::/64 2001:fork:lift::host > > In case 2, we don't do this. There are many reasons perhaps why we > might not do this --- perhaps the sensors in the forklift must interact > a lot with a lot of devices that are nearby. YEs - and the first one is the big red round button ("mushroom"?) which stops everything. Every automated device has such a "mushroom" triggered by humans in an emergency, its on/off state is of paramount importance to the control room. > In case 2, do those nodes speak RPL, or does the edge router(s) do RA/RS? > > (I don't have an answer. I think that layer-2 bridging like case 2 is > IPv4 think, and routing is a better choice) Don't have the nodes on the forklift talk RPL, no need, no requirement. They're simple and small, they'd hardly host an IP stack in the first place. Have something special on the forklift's bigger Mobile Router(?) do special things. Alex From pister@eecs.berkeley.edu Thu May 6 14:27:53 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IPaddress X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 jeonggil.ko@gmail.com Thu May 6 23:24:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D70F3A6883 for ; Thu, 6 May 2010 23:24:30 -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 OxsL47WfsvGP for ; Thu, 6 May 2010 23:24:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 548193A69EF for ; Thu, 6 May 2010 23:24:25 -0700 (PDT) Received: by vws9 with SMTP id 9so765629vws.31 for ; Thu, 06 May 2010 23:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=NVYQL7y/Qs/wfCPu3OHyRyyZ8QBLJS8DSAfosfCiZsI=; b=tOq6zCrRqq6HTE86+VKOERjt0JtBcLBGq2gvdIG7PbBBpI5nm8nZzyHfxMxG+4jMUE tLA/JqQJUEbZhS3+tWO9yuWprfAjLpJ1paDRCA+HgISKQulkA4jraGvPtdA2tw/mtpmv xDSrJdodNGjJvNRgNVQxWmJBCXgeaXy4/MZio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; b=E1vADN7vt4j5rnMX7aQaYDc7wY/7cbW6mXslTAXuHInocNq7zyze0y0WWYqTXuv0we +XJyU6pFkrOJK5ZBfsQKqsimSgYZctWnYa7oAQ1lp75yDAWXA5PGnHwV4QM7gX7eB4kZ GsnBdB4mJnKNXqS2/254qzhGfvE3RPgg+gqjw= Received: by 10.220.124.84 with SMTP id t20mr416055vcr.234.1273213448388; Thu, 06 May 2010 23:24:08 -0700 (PDT) Received: from c-68-48-231-220.hsd1.md.comcast.net (c-68-48-231-220.hsd1.md.comcast.net [68.48.231.220]) by mx.google.com with ESMTPS id x6sm7956750vco.11.2010.05.06.23.24.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 May 2010 23:24:07 -0700 (PDT) Sender: "JeongGil (John) Ko" From: "JeongGil Ko (John)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 7 May 2010 02:24:05 -0400 Message-Id: <6AAA6AEF-11B3-4342-BEA3-6D6D39E8154C@cs.jhu.edu> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Roll] Source Routing Header Format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 06:24:30 -0000 Hi all, Have we decided on what the routing header format will be for = point-to-point routing? The last discussion that I remember concluded with "Let's do something = like RH0 and do tag/labels for addressing". Do we have anything else after that? -John ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From abr@sdesigns.dk Fri May 7 00:02:45 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IPaddress X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 abr@sdesigns.dk Fri May 7 02:34:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D323A67AE for ; Fri, 7 May 2010 02:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.767 X-Spam-Level: X-Spam-Status: No, score=-0.767 tagged_above=-999 required=5 tests=[AWL=-0.582, 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 gFqgPGlLf4Ru for ; Fri, 7 May 2010 02:34:12 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 77C133A63EC for ; Fri, 7 May 2010 02:34:04 -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: Fri, 7 May 2010 11:33:51 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A11F@zensys17.zensys.local> In-Reply-To: <6AAA6AEF-11B3-4342-BEA3-6D6D39E8154C@cs.jhu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Source Routing Header Format in RPL Thread-Index: Acrtre9G7F8Kv8xVQSW+Hc79L6qsJwAGe4ig References: <6AAA6AEF-11B3-4342-BEA3-6D6D39E8154C@cs.jhu.edu> From: "Anders Brandt" To: "JeongGil Ko (John)" , "ROLL WG" Subject: Re: [Roll] Source Routing Header Format in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 09:34:13 -0000 Hi John You are completely right that we should get into that discussion now. It relates very much to the next phase of our work on P2P support and reactive discovery for non-storing nodes. draft-dt-roll-p2p-rpl-00 provides the basis for this discussion. If you have specific proposals for source routing support in RPL, please come forward ;-) - Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of JeongGil Ko (John) > Sent: Friday, May 07, 2010 08:24 > To: ROLL WG > Subject: [Roll] Source Routing Header Format >=20 > Hi all, >=20 > Have we decided on what the routing header format will be for=20 > point-to-point routing? > The last discussion that I remember concluded with "Let's do=20 > something like RH0 and do tag/labels for addressing". > Do we have anything else after that? >=20 > -John >=20 > ------ > JeongGil Ko (John) > Ph.D. Student > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From pthubert@cisco.com Fri May 7 05:48:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IPaddress X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IPaddress X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IPaddress X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 adam@sics.se Fri May 7 07:28:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7341E3A6B29 for ; Fri, 7 May 2010 07:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Gb43-c3TdRcY for ; Fri, 7 May 2010 07:28:36 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 6D7843A6AB2 for ; Fri, 7 May 2010 07:28:36 -0700 (PDT) Received: from [193.10.67.188] (floria.sics.se [193.10.67.188]) by letter.sics.se (Postfix) with ESMTPS id EF8F840121 for ; Fri, 7 May 2010 16:28:22 +0200 (CEST) Message-ID: <4BE42382.30104@sics.se> Date: Fri, 07 May 2010 16:28:18 +0200 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] FYI: RPL implementation in Contiki X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 14:28:37 -0000 Hi all, FYI: there is an open source implementation of RPL available in Contiki: http://www.sics.se/contiki/tutorials/contikirpl-the-new-default-contiki-ipv6/6lowpan-routing-protocol.html /adam -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From pthubert@cisco.com Fri May 7 07:34:08 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 mcr@sandelman.ca Fri May 7 09:04:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75BC33A6A8B for ; Fri, 7 May 2010 09:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, 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 9cOA0FfzDnWP for ; Fri, 7 May 2010 09:04:51 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 862683A6ADD for ; Fri, 7 May 2010 09:04:50 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id E543E34A54; Fri, 7 May 2010 12:04:37 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 36CCE4E7CC; Fri, 7 May 2010 12:04:37 -0400 (EDT) From: Michael Richardson To: Alexandru Petrescu In-Reply-To: <4BE3041F.7030400@gmail.com> References: <10172.1273160224@marajade.sandelman.ca> <4BE3041F.7030400@gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 07 May 2010 12:04:37 -0400 Message-ID: <13543.1273248277@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] host only nodes in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 16:04:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Alexandru" == Alexandru Petrescu writes: >> 2) the forklift has one or more interface nodes, it runs RPL on >> one interface, and implements (layer-2) a network bridge to the >> other interface. >> >> In case 1, we can use all sorts of network routing protocols to >> make the subnet for the forklift reachable on the RPL network. A >> grounded RPL uplink node can do things as simple as: route add >> -net 2001:fork:lift:gate::/64 2001:fork:lift::host >> >> In case 2, we don't do this. There are many reasons perhaps why >> we might not do this --- perhaps the sensors in the forklift must >> interact a lot with a lot of devices that are nearby. Alexandru> YEs - and the first one is the big red round button Alexandru> ("mushroom"?) which stops everything. Every automated Alexandru> device has such a "mushroom" triggered by humans in an Alexandru> emergency, its on/off state is of paramount importance to Alexandru> the control room. >> In case 2, do those nodes speak RPL, or does the edge router(s) >> do RA/RS? >> >> (I don't have an answer. I think that layer-2 bridging like case >> 2 is IPv4 think, and routing is a better choice) Alexandru> Don't have the nodes on the forklift talk RPL, no need, Alexandru> no requirement. They're simple and small, they'd hardly Alexandru> host an IP stack in the first place. Have something Alexandru> special on the forklift's bigger Mobile Router(?) do Alexandru> special things. So, I agree that this is better. I am assuming that the sensors host an IP stack, because if they don't, then the example becomes moot. Given that they host an IP stack, if the forklift has a mobile router on board, then the sensors do not need to speak RPL. The mobile router can speak RPL on one interface, and then do RA/RS with the nodes on the other. What this amounts to is that there are few reasons to have "host-only" nodes in RPL. There may many "leaf-nodes" in an RPL network, and they need to speak RPL because they don't know which "router-node" they are going to connect to, while on the forklift, there sensors are connected via wires, etc. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS+Q6E4CLcPvd0N1lAQKWhAf+Jjype+icX4CGGw4HfxuAMws1m2UQdZRb 6IhqSTlbEEs5XUG2Wbh9a8ikKAqgDTibkzYBs3lMMRTs8JKTd6Fq8zRbB9IVy8Qy RJxTlRU6oQxIDBCajOvHmtbPCc2y3XOrxBfrja80cw5lNYpubab+WLb6bmJ2KJ7V NJ0YOdVTAHkFxZ4S4AM8LorsssAtxrsX/kOqSVbU7Hrg+VeagRFMmzZeRwTsny+t OlW9OfOP8KxxEhgv6PA4+kQnho/VVPcSj/c8isyGjCHVbMDuWetgiDC5BSLvzytb 4JNB5LOI7zzhoU2UKXEthVb2JGYfTJ6nB6ounBwNmHhxm0DqJ6pl2Q== =dzQa -----END PGP SIGNATURE----- From alexandru.petrescu@gmail.com Fri May 7 09:17:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF063A6A12 for ; Fri, 7 May 2010 09:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_50=0.001, HELO_EQ_FR=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 rwxrd2SAwYVy for ; Fri, 7 May 2010 09:17:53 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id F37B83A6869 for ; Fri, 7 May 2010 09:17:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o47GHcHf021500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 May 2010 18:17:38 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o47GHbbM024709; Fri, 7 May 2010 18:17:37 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o47GHbLT026168; Fri, 7 May 2010 18:17:37 +0200 Message-ID: <4BE43D21.6000105@gmail.com> Date: Fri, 07 May 2010 18:17:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Michael Richardson References: <10172.1273160224@marajade.sandelman.ca> <4BE3041F.7030400@gmail.com> <13543.1273248277@marajade.sandelman.ca> In-Reply-To: <13543.1273248277@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] host only nodes in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 16:17:54 -0000 Le 07/05/2010 18:04, Michael Richardson a écrit : > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > >>>>>> "Alexandru" == Alexandru >>>>>> Petrescu writes: >>> 2) the forklift has one or more interface nodes, it runs RPL on >>> one interface, and implements (layer-2) a network bridge to the >>> other interface. >>> >>> In case 1, we can use all sorts of network routing protocols to >>> make the subnet for the forklift reachable on the RPL network. A >>> grounded RPL uplink node can do things as simple as: route add >>> -net 2001:fork:lift:gate::/64 2001:fork:lift::host >>> >>> In case 2, we don't do this. There are many reasons perhaps why >>> we might not do this --- perhaps the sensors in the forklift must >>> interact a lot with a lot of devices that are nearby. > > Alexandru> YEs - and the first one is the big red round button > Alexandru> ("mushroom"?) which stops everything. Every automated > Alexandru> device has such a "mushroom" triggered by humans in an > Alexandru> emergency, its on/off state is of paramount importance > to Alexandru> the control room. > >>> In case 2, do those nodes speak RPL, or does the edge router(s) >>> do RA/RS? >>> >>> (I don't have an answer. I think that layer-2 bridging like >>> case 2 is IPv4 think, and routing is a better choice) > > Alexandru> Don't have the nodes on the forklift talk RPL, no need, > Alexandru> no requirement. They're simple and small, they'd hardly > Alexandru> host an IP stack in the first place. Have something > Alexandru> special on the forklift's bigger Mobile Router(?) do > Alexandru> special things. > > So, I agree that this is better. I am assuming that the sensors host > an IP stack, because if they don't, then the example becomes moot. I agree. > Given that they host an IP stack, if the forklift has a mobile > router on board, then the sensors do not need to speak RPL. I agree: the sensors on the forklift do not need to speak RPL. > The mobile router can speak RPL on one interface, and then do RA/RS > with the nodes on the other. I agree 100% with the second part - onboard MR speaks RA/RS with the nodes on the foklift. What MR runs on its egress interface depends on many other factors. > What this amounts to is that there are few reasons to have > "host-only" nodes in RPL. Ok. But one must be sure that a node running RPL (the MR?) also runs RS/RA towards a host-only. You may want a Router which runs both RPL and RS/RA. Considering RPL only between RPL nodes without caring about hosts-only breaks many things - it's not connected to the Internet. > There may many "leaf-nodes" in an RPL network, and they need to > speak RPL because they don't know which "router-node" I disagree. An RPL network should support hosts-only connecting to it, and all connected to the Internet. Actually it's the leaf node host-only which should dictate what happens here. Not RPL. And a host-only leafnode runs RS/RA first. If it has spare memory then runs additional things like RPL. IMHO. Alex > they are going to connect to, while on the forklift, there sensors > are connected via wires, etc. > > - -- ] He who is tired of Weird Al is tired of life! | > firewalls [ ] Michael Richardson, Sandelman Software Works, > Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch > the video then sign the > petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 > (GNU/Linux) Comment: Finger me for keys > > iQEVAwUBS+Q6E4CLcPvd0N1lAQKWhAf+Jjype+icX4CGGw4HfxuAMws1m2UQdZRb > 6IhqSTlbEEs5XUG2Wbh9a8ikKAqgDTibkzYBs3lMMRTs8JKTd6Fq8zRbB9IVy8Qy > RJxTlRU6oQxIDBCajOvHmtbPCc2y3XOrxBfrja80cw5lNYpubab+WLb6bmJ2KJ7V > NJ0YOdVTAHkFxZ4S4AM8LorsssAtxrsX/kOqSVbU7Hrg+VeagRFMmzZeRwTsny+t > OlW9OfOP8KxxEhgv6PA4+kQnho/VVPcSj/c8isyGjCHVbMDuWetgiDC5BSLvzytb > 4JNB5LOI7zzhoU2UKXEthVb2JGYfTJ6nB6ounBwNmHhxm0DqJ6pl2Q== =dzQa > -----END PGP SIGNATURE----- > From mcr@sandelman.ca Fri May 7 13:01:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753DB3A69A2 for ; Fri, 7 May 2010 13:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.772 X-Spam-Level: X-Spam-Status: No, score=0.772 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, 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 7tp6RpumxxzE for ; Fri, 7 May 2010 13:01:34 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 1A3AA3A6980 for ; Fri, 7 May 2010 13:01:33 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 8F81734A91; Fri, 7 May 2010 16:01:21 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id D89314E7D6; Fri, 7 May 2010 16:01:20 -0400 (EDT) From: Michael Richardson To: Alexandru Petrescu In-Reply-To: <4BE43D21.6000105@gmail.com> References: <10172.1273160224@marajade.sandelman.ca> <4BE3041F.7030400@gmail.com> <13543.1273248277@marajade.sandelman.ca> <4BE43D21.6000105@gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 07 May 2010 16:01:20 -0400 Message-ID: <30871.1273262480@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] host only nodes in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 20:01:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Alexandru" == Alexandru Petrescu writes: >> So, I agree that this is better. I am assuming that the sensors >> host an IP stack, because if they don't, then the example becomes >> moot. Alexandru> I agree. >> Given that they host an IP stack, if the forklift has a mobile >> router on board, then the sensors do not need to speak RPL. Alexandru> I agree: the sensors on the forklift do not need to speak Alexandru> RPL. >> The mobile router can speak RPL on one interface, and then do >> RA/RS with the nodes on the other. Alexandru> I agree 100% with the second part - onboard MR speaks Alexandru> RA/RS with the nodes on the foklift. What MR runs on its Alexandru> egress interface depends on many other factors. okay, but if it isn't speaking RPL, then it's out of scope. >> What this amounts to is that there are few reasons to have >> "host-only" nodes in RPL. Alexandru> Ok. But one must be sure that a node running RPL (the Alexandru> MR?) also runs RS/RA towards a host-only. You may want a Alexandru> Router which runs both RPL and RS/RA. Alexandru> Considering RPL only between RPL nodes without caring Alexandru> about hosts-only breaks many things - it's not connected Alexandru> to the Internet. huh? Can you explain what you mean? >> There may many "leaf-nodes" in an RPL network, and they need to >> speak RPL because they don't know which "router-node" Alexandru> I disagree. An RPL network should support hosts-only Alexandru> connecting to it, and all connected to the Internet. Alexandru> Actually it's the leaf node host-only which should Alexandru> dictate what happens here. Not RPL. And a host-only Alexandru> leafnode runs RS/RA first. If it has spare memory then Alexandru> runs additional things like RPL. okay, I'd like to know what node replies to the RS for the host-only. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS+RxjoCLcPvd0N1lAQIfLQgAirfLTqauaNwyj+frdIr6rt4Q3d43IxdL 0VafUInZ5481cJnmt359ktxIcjp9uIajF9TkTFaRnhSajqo2kfwSLomJDOpAnDbh gsaSTSE2Pn7j30nSdPHRPk8HxvcjSf0fVD2qHsKhY/fWwlni5Px6JUT4Q4BbHE5V uROzjzdvpQAQ2ySoP4DScyON6Pa0pYWS1slDoygvjFs3g6gBBI0PryQI3I0AhD4r FEVO5CgQ2e0pfSVitgbTOTAwUEnIMGFz8LCwDZh1/WEs37P8wi8hdT6nI5jI5JAm 0MgbVovVsybLQzDI4UKzw5GzPsJDPyL1bKkxKxYRIhTMIrn2XhdEng== =xp7J -----END PGP SIGNATURE----- From alexandru.petrescu@gmail.com Fri May 7 13:26:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588DC3A696D for ; Fri, 7 May 2010 13:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.035 X-Spam-Level: X-Spam-Status: No, score=0.035 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_50=0.001, HELO_EQ_FR=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 qJPl6bA3ALUS for ; Fri, 7 May 2010 13:26:29 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6703A6958 for ; Fri, 7 May 2010 13:26:27 -0700 (PDT) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 54B3394014A; Fri, 7 May 2010 22:26:11 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP; Fri, 7 May 2010 22:26:10 +0200 (CEST) Message-ID: <4BE4775F.4090703@gmail.com> Date: Fri, 07 May 2010 22:26:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Michael Richardson References: <10172.1273160224@marajade.sandelman.ca> <4BE3041F.7030400@gmail.com> <13543.1273248277@marajade.sandelman.ca> <4BE43D21.6000105@gmail.com> <30871.1273262480@marajade.sandelman.ca> In-Reply-To: <30871.1273262480@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100507-0, 07/05/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] host only nodes in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 20:26:30 -0000 [I wish I had gnus to cite replies as you do...] Le 07/05/2010 22:01, Michael Richardson a écrit : >>>>>> "Alexandru" == Alexandru >>>>>> Petrescu writes: >>> So, I agree that this is better. I am assuming that the sensors >>> host an IP stack, because if they don't, then the example >>> becomes moot. > > Alexandru> I agree. > >>> Given that they host an IP stack, if the forklift has a mobile >>> router on board, then the sensors do not need to speak RPL. > > Alexandru> I agree: the sensors on the forklift do not need to > speak Alexandru> RPL. > >>> The mobile router can speak RPL on one interface, and then do >>> RA/RS with the nodes on the other. > > Alexandru> I agree 100% with the second part - onboard MR speaks > Alexandru> RA/RS with the nodes on the foklift. What MR runs on > its Alexandru> egress interface depends on many other factors. > > okay, but if it isn't speaking RPL, then it's out of scope. I agree the forklift router has at least two interfaces: one presumably RPL and the other surely RS/RA non-RPL. Forklift in hangar is a good case. (I believe the scenario is to have a forklift router which has at least two interfaces - one presumably running RPL. And the other interface, the one important to this discussion - the one _not_ running RPL in any case, just doing RS/RA to the mushroom button.) >>> What this amounts to is that there are few reasons to have >>> "host-only" nodes in RPL. > > Alexandru> Ok. But one must be sure that a node running RPL (the > Alexandru> MR?) also runs RS/RA towards a host-only. You may want > a Alexandru> Router which runs both RPL and RS/RA. > > Alexandru> Considering RPL only between RPL nodes without caring > Alexandru> about hosts-only breaks many things - it's not connected > Alexandru> to the Internet. > > huh? Can you explain what you mean? An RPL network to which my non-RPL PDA can't connect? Such a network is broken - don't use it. I mean that if one builds an RPL network incapable of hosting non-RPL host-only leaf nodes then one does this for nothing, i.e. disconnected from the Internet. One could as well do RPL somewhere else than IETF. Try to connect a non-RPL host to it and its ND breaks, base header fields are badly understood and so on - no Internet. >>> There may many "leaf-nodes" in an RPL network, and they need to >>> speak RPL because they don't know which "router-node" > > Alexandru> I disagree. An RPL network should support hosts-only > Alexandru> connecting to it, and all connected to the Internet. > > Alexandru> Actually it's the leaf node host-only which should > Alexandru> dictate what happens here. Not RPL. And a host-only > Alexandru> leafnode runs RS/RA first. If it has spare memory then > Alexandru> runs additional things like RPL. > > okay, I'd like to know what node replies to the RS for the > host-only. If the RPL Router sends a non-RPL RS on the interface towards a non-RPL node then the node will know what to reply, according to the Neighbor Discovery RFCs. I meant to say that the RPL router should be able to act as a non-RPL RS/RA on its interface on which a non-RPL host will connect. Otherwise RPL router is useless. In this sense, the RPL Router should follow what the non-RPL host needs. Alex From robert.cragie@gridmerge.com Sat May 8 05:53:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148943A6A82 for ; Sat, 8 May 2010 05:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 TiyZLWowqX72 for ; Sat, 8 May 2010 05:53:22 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 5169D3A6A88 for ; Sat, 8 May 2010 05:49:42 -0700 (PDT) Received: from host02.distrikthotelips2.d.subnet.rcn.com ([207.96.107.82] helo=[10.4.0.146]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OAjT9-0002u9-DJ; Sat, 08 May 2010 13:49:25 +0100 Message-ID: <4BE55DCB.2070204@gridmerge.com> Date: Sat, 08 May 2010 13:49:15 +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: "Pascal Thubert (pthubert)" References: <7069.1272031181@marajade.sandelman.ca><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> <6A2A459175DABE4BB11DE2026AA50A5D01D608E0@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01D608E0@XMB-AMS-107.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060203030903010105000801" Cc: roll@ietf.org, zach.shelby@sensinode.com Subject: Re: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 12:53:31 -0000 This is a cryptographically signed message in MIME format. --------------ms060203030903010105000801 Content-Type: multipart/alternative; boundary="------------030807090608080009050709" This is a multi-part message in MIME format. --------------030807090608080009050709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Pascal, I'm sending this just to ROLL as the ND part is waning. Comments inline, = bracketed by . 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 3:33 PM, Pascal Thubert (pthubert) wrote: > > 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=20 > does not help a host that needs to select a router that serves that=20 > instance. A plain host (that does not support RPL) will need to find=20 > that in RAs. In a same fashion, it will need to place what it's=20 > looking for in RS (like we'll do in DIS). And the new ND registration=20 > will have to indicate into which instances the registration must be=20 > injected as a DAO. > > Do you agree so far? > Yes > > The DODAG ID is not the appropriate information for the host, unless=20 > it is concerned with DAG multihoming and such, which I would not expect= =2E > > The router can and will switch DODAG within the instance and the host=20 > will not care, since its applications will be served either way. > If you mean switch selection of DODAG based on destination at the=20 point of packet ingress, and keep the same notion of ID (presumably=20 carrying it in the flow label?) whilst it propagates, yes. But I don't=20 see how it can switch from router to router or else we could end up with = the looping problem. > > 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=20 > unreachable code. > > Finally, a root might use the same DODAG ID in multiple instances. So=20 > the router could be confused if the host only indicated a DODAG ID... > > Still in agreement? > Yes - I see the combination of RPL instance ID to select the 'QoS'=20 (for want of a better expression) for the packet and the DODAG ID to=20 select which DODAG pertinent to the destination. > > On the side, we discussed for P2P about making local instances that=20 > actually depend on the DODAG ID so that the fully qualified instance=20 > ID would really be the tupple (DODAG ID, instanceID). That's still in=20 > limbo though I do think we need it. > > What's your take on this? > I am not sure if we need to distinguish another instance within a=20 DODAG for these 'skinny' P2P DAGs which were are discussing, simply=20 because, as far as I can see, the DODAG ID pertains to its destination.=20 Therefore providing we allocate a DODAG ID to the 'skinny' P2P DAGs then = I believe it will work in the same way. But I guess this needs further=20 discussion. > > 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;=20 > 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=20 > potentially different metrics (that's the point of them, right?), you=20 > would need some sort of qualification at the packet originator as to=20 > which RPL instance it ends up choosing for its route to its=20 > destination. This is done using the flow label. > > On the other hand, a DODAG is, as its name implies, a destination=20 > oriented DAG. Therefore the DODAG ID is the general discriminator=20 > within a RPL instance for which route a packet takes based on its=20 > destination. There is no need for any other additional information,=20 > surely? So that's what the +1 was for. > > The spec. seems a little confused on this anyway. In section 7.2 it=20 > says the RPLInstanceID field is an "8-bit field indicating the DODAG=20 > 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=20 > find the instances confusing, as they are often considered as a tuple=20 > (RPLID, DODAGID, DODAGSeqNum). However, transitioning from (1,1,1) to=20 > (1,1,2) is not the same as transitioning from (1,1,1) to (1,2,1) and=20 > 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=20 > with different requirements. > > The instance is the network response to the application needs. The=20 > application resides in the host, even if routers sometimes play both=20 > 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=20 > instances that it needs. That must be signaled in the router to host=20 > interface. > > The host also needs to be advertised in the RPL networks that support=20 > the instances that it needs. That must be signaled in the host to=20 > 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=20 > 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)" > > =20 > > [Pascal] 6LoWPAN ND needs some addition to enable RPL aware hos= ts. 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. > > =20 > > -Richard Kelsey > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > =20 > > =20 > --------------030807090608080009050709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Pascal,

I'm sending this just to ROLL as the ND part is waning. Comments inline, bracketed by <RCC></RCC>.

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 3:33 PM, Pascal Thubert (pthubert) wrote:

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 loo= king 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?

<RCC>Yes</RCC>

 

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.

<RCC>If you mean switch selection of DODAG based on destination at the point of packet ingress, and keep the same notion of ID (presumably carrying it in the flow label?) whilst it propagates, yes. But I don't see how it can switch from router to router or else we could end up with the looping problem.</RCC>

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?

<RCC>Yes - I see the combination of RPL instance ID to select the 'QoS' (for want of a better expression) for the packet and the DODAG ID to select which DODAG pertinent to the destination.</RCC>

 

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?

<RCC>I am not sure if we need to distinguish another instance within a DODAG for these 'skinny' P2P DAGs which were are discussing, simply because, as far as I can see, the DODAG ID pertains to its destination. Therefore providing we allocate a DODAG ID to the 'skinny' P2P DAGs then I believe it will work in the same way. But I guess this needs further discussion.</RCC>

 

 

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.or= g; 6l= owpan@ietf.org
Subject: Re: [Roll] [6lowpan] how does a node get an IP address<= o:p>

 

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://w= ww.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. <= o:p>

 

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

 

Well, -1.

 

Pascal

 

From: Robert Cragie [mailto:robert.cragie@gridmer= ge.com]
Sent: Thursday, May 06, 2010 7:48 PM
To: Richard Kelsey
Cc: Pascal Thubert (pthubert); zach.shelby@sensinode.com;= roll@ietf.o= rg; 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 ho=
sts. In
particular around instance IDs. 
    
 
Pascal, I disagree with "needs".  The ability to select an<=
o:p>
instance ID for a particular message is an optional extra.<=
/o:p>
RPL works fine without it.  I am okay with limiting instanc=
e
ID selection to routers.
 
          &nbs=
p;            =
;          -Richard Kelsey
_______________________________________________
= 
Roll mailing list
Roll@i=
etf.org
https://www.ietf.org=
/mailman/listinfo/roll
 
 
--------------030807090608080009050709-- --------------ms060203030903010105000801 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 MDgxMjQ5MTZaMCMGCSqGSIb3DQEJBDEWBBQ6E1pQXoP9rWEb6g7IAl2m+7WWozBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAJk9zTNRQgfkrnhuFPfVGgw+2zu3h//hrVnKT1o+GtkGjns484JA0JlFGQxkkh6kZe9Y WMU5tY50m4ikgkz/pxtUWSfGEcIoH0Q1aw0186oGKUBioYLc2OqbRMGNGNQwm7Pmw0/xgWUF FGtVxPMEvZ/Jlg5+zwhwzQkFMmZMGCCThQCq2lBAXmCODL36eJyXZbxlAVw1Uule38srkpBV vQ9K2hKjEHvTjJbheYFguyPtSxKGwv7MoPoill5OsVSQY+3grpMI1wxJtnS3mEs7iIcxCwmY wia1ZSP49l3X4+YubNABeWYv5TLF3uFL2glxC1rybYv1BJpsHOGuivENVHAAAAAAAAA= --------------ms060203030903010105000801-- From pthubert@cisco.com Sun May 9 09:27:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FE713A6A58 for ; Sun, 9 May 2010 09:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.559 X-Spam-Level: X-Spam-Status: No, score=-7.559 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_50=0.001, 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 7cqgyi8MusF3 for ; Sun, 9 May 2010 09:27:43 -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 7F8CC3A6A4A for ; Sun, 9 May 2010 09:27:39 -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: AtEBAKt/5kuQ/uCWiWdsb2JhbACBP5xWFQEBAQoLEREGHKJOmC+FFQQ X-IronPort-AV: E=Sophos;i="4.52,357,1270425600"; d="scan'208,217";a="60935928" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 May 2010 16:27:26 +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 o49GRQPa010849; Sun, 9 May 2010 16:27:26 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); Sun, 9 May 2010 18:27:26 +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_01CAEF94.82A41A8E" Date: Sun, 9 May 2010 18:27:23 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01D60A34@XMB-AMS-107.cisco.com> In-Reply-To: <4BE55DCB.2070204@gridmerge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [6lowpan] how does a node get an IP address Thread-Index: AcrurOgOM6Rtr+0YTNOOObjfa7OiIgA5vZng References: <7069.1272031181@marajade.sandelman.ca><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> <6A2A459175DABE4BB11DE2026AA50A5D01D608E0@XMB-AMS-107.cisco.com> <4BE55DCB.2070204@gridmerge.com> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 09 May 2010 16:27:26.0361 (UTC) FILETIME=[82E34090:01CAEF94] Cc: roll@ietf.org, zach.shelby@sensinode.com Subject: Re: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 16:27:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAEF94.82A41A8E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert: =20 The purpose of the local instance ID is to enable a node to form an instance ID that does not have to be unique in the subnet. A node A that needs to form a DODAG to talk to node B under specific constraints would pick one of its addresses as DADOGID, and autoconf an instanceID without the need to agree with anyone. =20 This comes with the assumption that globally unique instance IDs will be scarce resource and might involve some work to get assigned, whereas an instance ID that is only locally unique (for a DODAGID) is a lot easier to get. If some P2P flows require quick set up, this might come handy... =20 Cheers, =20 Pascal =20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: Saturday, May 08, 2010 2:49 PM To: Pascal Thubert (pthubert) Cc: Richard Kelsey; zach.shelby@sensinode.com; roll@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IP address =20 Hi Pascal,=20 I'm sending this just to ROLL as the ND part is waning. Comments inline, bracketed by . 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 3:33 PM, Pascal Thubert (pthubert) wrote:=20 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? Yes =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 If you mean switch selection of DODAG based on destination at the point of packet ingress, and keep the same notion of ID (presumably carrying it in the flow label?) whilst it propagates, yes. But I don't see how it can switch from router to router or else we could end up with the looping problem. 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? Yes - I see the combination of RPL instance ID to select the 'QoS' (for want of a better expression) for the packet and the DODAG ID to select which DODAG pertinent to the destination. =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? I am not sure if we need to distinguish another instance within a DODAG for these 'skinny' P2P DAGs which were are discussing, simply because, as far as I can see, the DODAG ID pertains to its destination. Therefore providing we allocate a DODAG ID to the 'skinny' P2P DAGs then I believe it will work in the same way. But I guess this needs further discussion. =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_01CAEF94.82A41A8E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert:

 

The purpose of the local instance ID is to enable a node to form an = instance ID that does not have to be unique in the subnet. A node A that = needs to form a DODAG to talk to node B under specific constraints would = pick one of its addresses as DADOGID, and autoconf an instanceID without = the need to agree with anyone.

 

This comes with the assumption that globally unique instance IDs will = be scarce resource and might involve some work to get assigned, whereas = an instance ID that is only locally unique (for a DODAGID) is a lot = easier to get. If some P2P flows require quick set up, this might come = handy…

 

Cheers,

 

Pascal

 

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

 

Hi Pascal, =

I'm sending this just to ROLL as the ND part is waning. Comments = inline, bracketed by = <RCC></RCC>.

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 3:33 PM, Pascal = Thubert (pthubert) wrote:

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?

<RCC>Yes</RCC>

 

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. =

<RCC>If you mean switch = selection of DODAG based on destination at the point of packet ingress, = and keep the same notion of ID (presumably carrying it in the flow = label?) whilst it propagates, yes. But I don't see how it can switch = from router to router or else we could end up with the looping = problem.</RCC>

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?

<RCC>Yes - I see the combination of RPL instance = ID to select the 'QoS' (for want of a better expression) for the packet = and the DODAG ID to select which DODAG pertinent to the = destination.</RCC>

 

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?

<RCC>I am not sure if we need to distinguish = another instance within a DODAG for these 'skinny' P2P DAGs which were = are discussing, simply because, as far as I can see, the DODAG ID = pertains to its destination. Therefore providing we allocate a DODAG ID = to the 'skinny' P2P DAGs then I believe it will work in the same way. = But I guess this needs further = discussion.</RCC>

 

 

Pascal

 

From: Robert Cragie [mailto:robert.cragie@gridmerg= e.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_01CAEF94.82A41A8E-- From pthubert@cisco.com Sun May 9 09:43:12 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 abr@sdesigns.dk Mon May 10 01:42:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 pthubert@cisco.com Mon May 10 02:07:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: 6lowpan@ietf.org, roll@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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, Erik Nordmark , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 erik.nordmark@oracle.com Mon May 10 04:47:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 pthubert@cisco.com Mon May 10 05:44:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 mcr@sandelman.ca Mon May 10 06:28:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73CD43A68A0 for ; Mon, 10 May 2010 06:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.637 X-Spam-Level: X-Spam-Status: No, score=0.637 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, 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 m7iBBYTHNsYf for ; Mon, 10 May 2010 06:28:27 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id D2BB83A6932 for ; Mon, 10 May 2010 06:28:25 -0700 (PDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 318BB34B72; Mon, 10 May 2010 09:28:14 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 2DCC23EC5; Mon, 10 May 2010 09:28:13 -0400 (EDT) From: Michael Richardson To: Alexandru Petrescu In-Reply-To: <4BE4775F.4090703@gmail.com> References: <10172.1273160224@marajade.sandelman.ca> <4BE3041F.7030400@gmail.com> <13543.1273248277@marajade.sandelman.ca> <4BE43D21.6000105@gmail.com> <30871.1273262480@marajade.sandelman.ca> <4BE4775F.4090703@gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 10 May 2010 09:28:13 -0400 Message-ID: <8054.1273498093@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] host only nodes in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 13:28:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Alexandru" == Alexandru Petrescu writes: Alexandru> [I wish I had gnus to cite replies as you do...] (NTEmacs runs on your platform, and thunderbird supports external editors..) mcr> What this amounts to is that there are few reasons to have mcr> "host-only" nodes in RPL. Alexandru> Ok. But one must be sure that a node running RPL (the Alexandru> MR?) also runs RS/RA towards a host-only. You may want Alexandru> a Router which runs both RPL and RS/RA. Alexandru> Considering RPL only between RPL nodes without caring Alexandru> about hosts-only breaks many things - it's not connected Alexandru> to the Internet. >> huh? Can you explain what you mean? Alexandru> An RPL network to which my non-RPL PDA can't connect? Alexandru> Such a network is broken - don't use it. Alexandru> I mean that if one builds an RPL network incapable of Alexandru> hosting non-RPL host-only leaf nodes then one does this Alexandru> for nothing, i.e. disconnected from the Internet. One Alexandru> could as well do RPL somewhere else than IETF. I think I've having a problem with the words here. For me, a "host-only" node is one that does not speak RPL. Versus, a "leaf" node is one that does speak RPL, but doesn't relay packets. Either due to capability or design, or because there are no nodes which have picked it as a parent. So a host-only leaf node is a contradiction to me. A host-only node talks RS/RA to something, such as in the forklift example, the "Mobile Router", and likely does it on a different layer-2. A leaf-node is part of the RPL, it's just at the bottom. Not-storing nodes in a storing network, for instance, would be forced to be leaf-only. Alexandru> I disagree. An RPL network should support hosts-only Alexandru> connecting to it, and all connected to the Internet. So again, what router is answering their RS/RA messages? Alexandru> Actually it's the leaf node host-only which should Alexandru> dictate what happens here. Not RPL. And a host-only Alexandru> leafnode runs RS/RA first. If it has spare memory then Alexandru> runs additional things like RPL. >> okay, I'd like to know what node replies to the RS for the >> host-only. Alexandru> If the RPL Router sends a non-RPL RS on the interface Alexandru> towards a non-RPL node then the node will know what to Alexandru> reply, according to the Neighbor Discovery RFCs. Alexandru> I meant to say that the RPL router should be able to act Alexandru> as a non-RPL RS/RA on its interface on which a non-RPL Alexandru> host will connect. Otherwise RPL router is useless. In Alexandru> this sense, the RPL Router should follow what the non-RPL Alexandru> host needs. Yes, on another interface, which is configured in a non-RPL way. Perhaps a diagram is in order. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS+gJ64CLcPvd0N1lAQI7dgf9F9SDbahoM8kI3lNwP1GcYsOG1XLhIb8m 50gS1HUbU6NdHivV0ks7S8eN8wjKOjNAObAR473ZZQH3mKrYDb7JAEAENHxcPjL4 5pefdx871ZudEnIZUsGioWvU2gh2SymbrmpgFsEdssXSisJoxgjqhNJ0M+uPkwmQ 34cHD/LR2+DRqmfKH2Gkn0Irlyl56EysRx4rbKkG7dIgqQfaBTYlS+Tg6KGB19l3 Qpzendf1CGWkvT1DJVdzWqcinPATqjeNNCwcloePxymMDi6D72YKGIeTyiqOT8Tk Ru6YCRjmenxNXQESty+KMzazgeXNj/F1+4totG/fHvyMIXetPExGcg== =BB4o -----END PGP SIGNATURE----- From d.sturek@att.net Mon May 10 06:41:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD58128C166 for ; 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 ea7VdTtpmg-q for ; Mon, 10 May 2010 06:41:51 -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 CDE7F3A6968 for ; 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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks 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 erik.nordmark@oracle.com Sun May 9 23:58:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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 X-Mailman-Approved-At: Mon, 10 May 2010 09:43:10 -0700 Cc: zach.shelby@sensinode.com, roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 01:31:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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 X-Mailman-Approved-At: Mon, 10 May 2010 09:43:11 -0700 Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 erik.nordmark@oracle.com Mon May 10 02:01:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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 X-Mailman-Approved-At: Mon, 10 May 2010 09:43:11 -0700 Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 gnawali@cs.stanford.edu Mon May 10 18:10:06 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13353A6ABB for ; Mon, 10 May 2010 18:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[AWL=-1.488, BAYES_99=3.5, FM_FORGED_GMAIL=0.622, 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 LwRl+qthSRT2 for ; Mon, 10 May 2010 18:10:04 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id A168F3A6AB9 for ; Mon, 10 May 2010 18:10:04 -0700 (PDT) Received: from mail-yw0-f173.google.com ([209.85.211.173]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1OBdyr-0002la-2Z for roll@ietf.org; Mon, 10 May 2010 18:09:53 -0700 Received: by ywh3 with SMTP id 3so1430542ywh.31 for ; Mon, 10 May 2010 18:09:52 -0700 (PDT) Received: by 10.150.170.11 with SMTP id s11mr8694810ybe.390.1273540192169; Mon, 10 May 2010 18:09:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.11.9 with HTTP; Mon, 10 May 2010 18:09:32 -0700 (PDT) In-Reply-To: References: From: Omprakash Gnawali Date: Mon, 10 May 2010 18:09:32 -0700 Message-ID: To: Matteo Paris Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: cb5916722246bf80bd9488153e8e2604 Cc: ROLL WG Subject: Re: [Roll] Some results on reducing control overhead using Trickle's suppression mechanism X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 01:10:06 -0000 On Sat, May 1, 2010 at 11:39 AM, Omprakash Gnawali wrote: > On Fri, Apr 30, 2010 at 8:27 AM, Matteo Paris wrote: >> >> Hi Om, thanks for this work. =A0I have some questions. >> >> The two graphs seem to use different data sets. =A0For example, looking = at the >> left bar graph for motelab for k =3D 10, it looks like about 10% suppres= sion >> as compared with k =3D infinity. =A0But looking at the CDF plot, it look= s like >> 50% suppression for k =3D 10. =A0The tutornet data does not fit either, = and the >> CDF graph does not indicate whether it is Motelab or Tutornet data. =A0T= he CDF >> graph counts "beacons suppressed", whereas the bar graph counts "control >> packets sent". Are there control packets that are not beacons? =A0I woul= d like >> to see both graphs for the same data set. > > Recall that beacon suppression mechanism does not suppress beacons > that are sent due to nodes requesting routes (PULL bit in CTP) and > datapath inconsitency. So, although we suppressed 50% of the would-be > beacons, that does not necessarily transate to 50% reduction in > control overhead. This explains the apparent discrepancy between the > two plots. Sorry, I should have included this in the explanation. The > CDF on the right is for Tutornet. I have noted this on the page now. > > >> To get a true picture of the impact of beacon suppression on delivery >> ratios, the experiment must be done on many different networks with >> different densities and topologies. =A0In particular, networks with nonu= niform >> density have a higher risk that beacon suppression will partition them. = =A0We >> can't conclude from only two data points that "beacon suppression can be >> used to reduce control overhead without any negative impact on routing >> performance". > > As I explained in my earlier email, this network has non-uniform > density. I found that suppression mechanism suppresses beacons to > different extent depending on the density. If we pick a threshold that > is not too aggressive, it does not partition the sparse parts of the > network (because it does not suppress the beacons) while reducing > control overhead on the denser parts of the network. > > It is hard to vary the physical density on the testbeds. I did another > series of experiment to at least emulate change in density -- run > experiments with different transmit power but the same redundancy > threshold of 10. These are presented as the second set of results on > this page: > http://stuff.stanford.edu/~om_p/ctp/beaconsuppression.html > > We can see that the suppression becomes more impactful at higher > density. At lower density, it does not suppress many beacons, which is > exactly what we want. I performed a new set of experiments exploring beacon suppression on channel 16 (overlapping WiFi). We expect the result to be noisier than channel 26, on which there is no WiFi traffic. The results are under the title "The Impact of WiFi interference on Beacon Suppression" at this link below: http://stuff.stanford.edu/~om_p/ctp/beaconsuppression.html - om_p From erik.nordmark@oracle.com Tue May 11 02:07:15 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 alexandru.petrescu@gmail.com Tue May 11 05:32:43 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9FF3A6CBE for ; Tue, 11 May 2010 05:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_50=0.001, HELO_EQ_FR=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 5rb4yLNFVY13 for ; Tue, 11 May 2010 05:32:42 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 01A353A6CFE for ; Tue, 11 May 2010 05:30:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o4BCTrax000486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 May 2010 14:29:53 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o4BCTqct015455; Tue, 11 May 2010 14:29:53 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o4BCTqgE004291; Tue, 11 May 2010 14:29:52 +0200 Message-ID: <4BE94DC0.5020305@gmail.com> Date: Tue, 11 May 2010 14:29:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Michael Richardson References: <10172.1273160224@marajade.sandelman.ca> <4BE3041F.7030400@gmail.com> <13543.1273248277@marajade.sandelman.ca> <4BE43D21.6000105@gmail.com> <30871.1273262480@marajade.sandelman.ca> <4BE4775F.4090703@gmail.com> <8054.1273498093@marajade.sandelman.ca> In-Reply-To: <8054.1273498093@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] host only nodes in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 12:32:43 -0000 Le 10/05/2010 15:28, Michael Richardson a écrit : [...] > >> huh? Can you explain what you mean? > > Alexandru> An RPL network to which my non-RPL PDA can't connect? > Alexandru> Such a network is broken - don't use it. > > Alexandru> I mean that if one builds an RPL network incapable of > Alexandru> hosting non-RPL host-only leaf nodes then one does this > Alexandru> for nothing, i.e. disconnected from the Internet. One > Alexandru> could as well do RPL somewhere else than IETF. > > I think I've having a problem with the words here. > > For me, a "host-only" node is one that does not speak RPL. > > Versus, a "leaf" node is one that does speak RPL, but doesn't relay > packets. Either due to capability or design, or because there > are no nodes which have picked it as a parent. > > So a host-only leaf node is a contradiction to me. I see what you mean. To me it is strange to call a leaf-node something which is not an end (in the TCP sense of "end-to-end"), i.e. something which is not a Host. You (this terminology definers) call it Leaf as if everything ended there. They forget the goal of this is to have routes for applications running on Hosts. RPL for the sake of RPL is to of much use. > A host-only node talks RS/RA to something, such as in the forklift > example, the "Mobile Router", and likely does it on a different layer-2. WEll no. The forklift Mobile Router could have Bluetooth on an interface and another Bluetooth on another interface, and route between the two. > A leaf-node is part of the RPL, it's just at the bottom. ... as if everything ended there - where are the applications running? > Not-storing nodes in a storing network, for instance, would be forced to > be leaf-only. RPL would run always on non-storing networks, I don't see the "store-and-forward" aspect in RPL, I think it's not intended so. > Alexandru> I disagree. An RPL network should support hosts-only > Alexandru> connecting to it, and all connected to the Internet. > > So again, what router is answering their RS/RA messages? Hmmm, I think the forklift RPL router must answer an non-RPL RS sent by a Host to it. If it doesn't then it's useless. > Alexandru> Actually it's the leaf node host-only which should > Alexandru> dictate what happens here. Not RPL. And a host-only > Alexandru> leafnode runs RS/RA first. If it has spare memory then > Alexandru> runs additional things like RPL. > > >> okay, I'd like to know what node replies to the RS for the > >> host-only. > > Alexandru> If the RPL Router sends a non-RPL RS on the interface > Alexandru> towards a non-RPL node then the node will know what to > Alexandru> reply, according to the Neighbor Discovery RFCs. > > Alexandru> I meant to say that the RPL router should be able to act > Alexandru> as a non-RPL RS/RA on its interface on which a non-RPL > Alexandru> host will connect. Otherwise RPL router is useless. In > Alexandru> this sense, the RPL Router should follow what the non-RPL > Alexandru> host needs. > > Yes, on another interface, which is configured in a non-RPL way. Well yes. So it is a Router which has an RPL interface and another non-RPL interface. Remark that RPL routers should also be able to run non-RPL RS/RA on their RPL interfaces, otherwise non-RPL Hosts connecting to their RPL interfaces will not be able to talk to them. > Perhaps a diagram is in order. Hm. Alex > > - -- > ] He who is tired of Weird Al is tired of life! | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video > then sign the petition. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Finger me for keys > > iQEVAwUBS+gJ64CLcPvd0N1lAQI7dgf9F9SDbahoM8kI3lNwP1GcYsOG1XLhIb8m > 50gS1HUbU6NdHivV0ks7S8eN8wjKOjNAObAR473ZZQH3mKrYDb7JAEAENHxcPjL4 > 5pefdx871ZudEnIZUsGioWvU2gh2SymbrmpgFsEdssXSisJoxgjqhNJ0M+uPkwmQ > 34cHD/LR2+DRqmfKH2Gkn0Irlyl56EysRx4rbKkG7dIgqQfaBTYlS+Tg6KGB19l3 > Qpzendf1CGWkvT1DJVdzWqcinPATqjeNNCwcloePxymMDi6D72YKGIeTyiqOT8Tk > Ru6YCRjmenxNXQESty+KMzazgeXNj/F1+4totG/fHvyMIXetPExGcg== > =BB4o > -----END PGP SIGNATURE----- > From samitac@ipinfusion.com Tue May 11 17:02:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988933A6B86 for ; 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 XBLJ2d+BJWfp for ; Tue, 11 May 2010 17:02:48 -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 D797F3A6A4C for ; 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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221913A6C3A for ; 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 qjdq7CEqX-gw for ; Tue, 11 May 2010 17:52:08 -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 AD6A83A6A2B for ; 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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 pal@cs.stanford.edu Wed May 12 14:59:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] [6lowpan] how does a node get an IP address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 therbst@silverspringnet.com Wed May 12 16:39:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381183A6853 for ; Wed, 12 May 2010 16:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[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 QfIVqBEhjb07 for ; Wed, 12 May 2010 16:39:39 -0700 (PDT) Received: from bachelor.silverspringnet.com (bachelor.silverspringnet.com [69.36.245.73]) by core3.amsl.com (Postfix) with ESMTP id 750FC3A67C1 for ; Wed, 12 May 2010 16:39:39 -0700 (PDT) Received: from IT-EXCA-02.silverspringnet.com ([10.200.1.62]) by bachelor.silverspringnet.com (8.14.1/8.13.8) with ESMTP id o4CNd7iU032029 for ; Wed, 12 May 2010 16:39:19 -0700 (PDT) Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-02.silverspringnet.com ([::1]) with mapi; Wed, 12 May 2010 16:39:07 -0700 From: Thomas Herbst To: "roll@ietf.org" Date: Wed, 12 May 2010 16:39:06 -0700 Thread-Topic: downward routing? Thread-Index: AcryLE/r3UQilcZNRDCM5ims92x+LQ== Message-ID: <485AF6ECE8D1954D996771CC49E996FDC0FE2B21@IT-EXMB-01.silverspringnet.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Roll] downward routing? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 23:39:41 -0000 Haven't seen anything on this for almost a month.=20 Is there progress on some flavor of hop-by-hop or source routing downward f= rom the DAG Root? RH0 going once, going twice...? Tom ---------------------------------------------------------------------------= -------------- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur Sent: Thursday, April 15, 2010 6:01 AM To: d.sturek@att.net Cc: roll@ietf.org Subject: Re: [Roll] Proposal for Source RoutingHeader Format and SourceRout= ingOperations Also my reading (again, co-chair hat off). On Apr 15, 2010, at 2:48 PM, Don Sturek wrote: Hi Pascal, =A0 I believe what you wrote below was the majority view on the reflector. =A0 Don =A0 =A0 From:=A0Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent:=A0Thursday, April 15, 2010 5:35 AM To:=A0JP Vasseur;=A0d.sturek@att.net Cc:=A0roll@ietf.org Subject:=A0RE: [Roll] Proposal for Source RoutingHeader Format and SourceRo= utingOperations =A0 Hi JP and all; =A0 I'm not fully clear what the WG group really wants to do at this point. I s= ensed an agreement to endorse something very close to IPv6 RH0 in the core = spec, and provide a separate spec that would enable labels in the Source ro= ute DAO and the hop by hop header. =A0 Is that a honest reading of the mailing list? =A0 Pascal =A0 From:=A0roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]=A0On Behalf Of= =A0JP Vasseur Sent:=A0Thursday, April 15, 2010 2:26 PM To:=A0d.sturek@att.net Cc:=A0roll@ietf.org Subject:=A0Re: [Roll] Proposal for Source RoutingHeader Format and SourceRo= utingOperations =A0 Hi Don, =A0 On Apr 8, 2010, at 4:59 PM, Don Sturek wrote: =A0 I think the issue is this: 1)=A0=A0=A0=A0=A0=A0=A0ROLL cannot meet its charter without source routing =A0 Absolutely. =A0 2)=A0=A0=A0=A0=A0=A0=A0Claiming the feature is now to be addressed in 6LowP= AN seems a bit wrong.=A0 ROLL has as its scope MAC/PHYs other than IEEE 802= .15.4.=A0 =A0 You are absolutely right. IPHC is 15.4 specific. This is why the idea of us= ing a Label a la MPLS would be an interesting approach IMO. The labe could = be locall significant using DAO as a label distribution mechanism. Complete= ly link layer agnostic. =A0 JP. =A0 How are those addressed? =A0 Don =A0 =A0 From:=A0Robert Cragie [mailto:robert.cragie@gridmerge.com] Sent:=A0Thursday, April 08, 2010 7:52 AM To:=A0d.sturek@att.net Cc:=A0daniel.gavelle@jennic.com;=A0roll@ietf.org Subject:=A0Re: [Roll] Proposal for Source Routing Header Format and SourceR= outingOperations =A0 Hi Don, It's not so much that 6lowpan is concerning itself with source routing, it = is concerning itself with efficient header compression, which would include= IPv6 extension headers such as=A0RH0. Whatever ends up getting used for so= urce routing needs to be some sort of IPv6 extension header. Source routing= for IPv6 would naturally contain IPv6 addresses. The question is whether w= e want to invent some new extension header specifically for ROLL which uses= something other (i.e. smaller) than IPv6 addresses, e.g. the tag scheme me= ntioned. I agree, ROLL must accommodate source routing one way or another. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 08/04/2010 2:35 PM, Don Sturek wrote: I can't see why 6LowPAN (and specifically the HC draft) would concern itsel= f with source routing. =A0 Surely source routing is a concern of ROLL (and not 6LowPAN). =A0 I don't see how ROLL completes its charter or addresses its requirements wi= thout adding source routing. =A0 Don =A0 =A0 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Dan= iel Gavelle Sent: Thursday, April 08, 2010 6:12 AM To: robert.cragie@gridmerge.com Cc: roll@ietf.org Subject: Re: [Roll] Proposal for Source Routing Header Format and SourceRou= tingOperations =A0 Rob, =A0 I agree that the source routing for the data frames should be done as part = of the 6LowPAN HC.=A0 This already has a stateful IPV6 address compression = based on contexts.=A0 It should be possible to compress the addresses down = to two bytes per address if IPv6 addresses are derived from the 16 bit shor= t address are being used in the LowPAN. =A0 We don't want to hold up the current HC draft that is going through last ca= ll but the work could be done as a new RFC / amendment.=A0 Source routing c= ompression may need a fix for the problem of HC compression extending beyon= d the first fragment. =A0 Doing the work in the 6LowPAN group means that the compression can easily b= e used for any source routing protocol, not just ROLL.=A0 It could be done = as a compression for the existing R0 routing header.=A0 Maybe this thread n= eeds moving to the 6LowPAN reflector. =A0 Daniel. =A0 =A0 Robert Cragie wrote: =A0=20 Hi Pascal, =A0 Source routing should of course use the IPv6 addresses which means a lot of= overhead for certain underlying link layers, e.g. 802.15.4. I think it is = generally cleaner to do the compression at a layer which may require it onl= y, e.g. define it in the 6lowpan HC. This is then free to some extent to sp= ecify how the compression is done. Although I doubt this would go down well= in the 6lowpan WG... =A0 The tag scheme would work but it specifically scopes the source routing to = nodes which operate the scheme. This is probably acceptable practically but= doesn't 'smell right' somehow. =A0 With regard to the original proposal: it is probably necessary to carry the= full source route all the way to at least the penultimate node and use an = index to show the current position in the route for potential backtrace and= error reporting back along the same route (assuming link symmetry). This i= s how RH0 works. =A0 Robert =A0 Robert Cragie (Pacific Gas & Electric) =A0 Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =A0 =A0 On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote: =A0=A0=A0=20 Hi Daniel: =A0 Routers might have multiple interfaces of multiple MAC types. Internet 0 ev= en has a MAC-less format. So the result of you proposal, which looks like a great idea in a pure 802.15.4 world with short addresses, becomes a nightmare to define in a ful= ly generic fashion. =A0 OTOH, a locally significant opaque tag in which the parent could hide a sho= rt address of the child - if it cares to do it that way - looks like a way = more acceptable approach =A0 So it seems to me that you can get what you want as long as we can make the= tag big enough for short addresses. When the tag is too small to contain w= hat the parent really needs, then the parent will have to store a state wit= h the full information in memory, and then place an index of some sort in t= he tag. =A0 What do you think? =A0 Pascal =A0 =A0 =A0=20 =A0=A0=A0=A0=A0=A0 -----Original Message----- From: Popa, Daniel [mailto:Daniel.Popa@itron.com] Sent: Thursday, April 08, 2010 11:40 AM To: ROLL WG Cc: Pascal Thubert (pthubert); JeongGil Ko (John) Subject: RE: [Roll] Proposal for Source Routing Header Format and SourceRou= tingOperations =A0 Hi Pascal, John, =A0 Since source routing explicitly gives forwarding instruction to each interm= ediate node, it can make sense to use only (MAC address based) =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 L2 =A0=20 =A0=A0=A0=A0=A0=A0 forwarding instead of (IPv6 address based) L3 forwarding. =A0 This brings two advantages: - avoid processing each transit packets up to L3. - use MAC addresses that - in ROLL environment - have inherently =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 shorter =A0=20 =A0=A0=A0=A0=A0=A0 length than an IPv6 address. =A0 Cheers, Daniel =A0 =A0 =A0 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 Of =A0=20 =A0=A0=A0=A0=A0=A0 Pascal Thubert (pthubert) Sent: jeudi 8 avril 2010 11:15 To: JeongGil Ko (John); ROLL WG Subject: Re: [Roll] Proposal for Source Routing Header Format and SourceRou= tingOperations =A0 Hi John: =A0 IPv6 already has a number of routing headers, in particular RH0, =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 though it is =A0=20 =A0=A0=A0=A0=A0=A0 being deprecated for general use in the Internet. And there are reasons why the fields in RH0/1 are there and we need to make= sure we lose none of that. In particular a RH is recoverable, and =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 it is =A0=20 =A0=A0=A0=A0=A0=A0 easy to spot the consumed entries. =A0 On top of this our new problems are: - make sure the RH stays within the RPL network (since it is used =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 downwards =A0=20 =A0=A0=A0=A0=A0=A0 that should be doable) - control the size (that probably means compress) =A0 Cheers, =A0 Pascal =A0 =A0 =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Of =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 JeongGil Ko (John) Sent: Wednesday, April 07, 2010 10:05 PM To: ROLL WG Subject: [Roll] Proposal for Source Routing Header Format and Source Routin= gOperations =A0 Hi! =A0 Great to see all this discussions on downwards route establishment! =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 To =A0=20 =A0=A0=A0=A0=A0=A0 add =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 one more to the conversations here is a proposal for source routing =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 headers. =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 In non-storing mode (where only the root has individual path =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 information) =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 the root will be attaching a source routing header to the data =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 packet =A0=20 =A0=A0=A0=A0=A0=A0 that a =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 source node wants to send to a specific destination. We can always =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 make the =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 header super fancy but in my opinion I think we only need two fields =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in this =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 header and here it is! Feel free to break the stuff and mangle with =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 it =A0=20 =A0=A0=A0=A0=A0=A0 so that it =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 looks great in the specs later on. FYI, this is the format that I am =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 using in my =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 implementations so it does work :) =A0 1. Source Routing Header Format =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=A0=A0 NEntry (8 bits)=A0=A0 | =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+ =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 + =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Source = Route Entry (128*NEntry bits) =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 + =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 + =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0 Figure 1. Proposed Source Routing Header Format; each line = is =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 32 =A0=20 =A0=A0=A0=A0=A0=A0 bits:) =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 - NEntry: Indicates the number of 128 bit addresses that the source =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 route =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 entry field is carrying. =A0 - Source Route Entry: List of 128 bit address that consist the route =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to the =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 destination. Here, the address of the node that is one hop away from =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 *destination* comes first. =A0 2. Source Routing Packet Operations =A0 When source routing is initiated at a storing node (e.g., root of =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the =A0=20 =A0=A0=A0=A0=A0=A0 DODAG), =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 the header is attached on the data packet for the entire route =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (i.e., =A0=20 =A0=A0=A0=A0=A0=A0 from =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 next hop node to the destination). This header is positioned in =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 front =A0=20 =A0=A0=A0=A0=A0=A0 of the =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 user payload. When the next hop node receives a packet that is not =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 destined =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 to itself AND the network is NOT provisioned to be in 'storing mode' =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 then it =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 checks NEntry to find what the next hop is in the source route =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 entry. =A0=20 =A0=A0=A0=A0=A0=A0 Since =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 the 'Source Route Entry' is ordered in 'farthest -> closest' (in =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 terms =A0=20 =A0=A0=A0=A0=A0=A0 of hops) =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 order, a node can figure out what the next hop address is with only =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 NEntry value (since it already knows how big an ipv6 address is). =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 After =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 collecting the next hop node's address, the node erases this address elemen= t from the entry and decreases NEntry by one. This assures =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 that =A0=20 =A0=A0=A0=A0=A0=A0 we =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 avoid the overhead of carrying the entire source route throughout =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the =A0=20 =A0=A0=A0=A0=A0=A0 data =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 path. =A0 The approach itself should be very simple and trivial for everyone =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 to =A0=20 =A0=A0=A0=A0=A0=A0 follow. =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 So we can start from here and build on! =A0 Thanks. =A0 -John =A0 ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko =A0 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =A0 =A0=20 =A0=A0=A0=A0=A0=A0 =A0 ------------------------------------------------------------------------ =A0 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =A0=A0=A0=20 =A0 =A0=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =A0 From trac@tools.ietf.org Thu May 13 08:46:01 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1123A6919 for ; Thu, 13 May 2010 08:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.47 X-Spam-Level: X-Spam-Status: No, score=-101.47 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_20=-0.74, 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 noac9vjEYqfr for ; Thu, 13 May 2010 08:46:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E61E93A6B7F for ; Thu, 13 May 2010 08:45:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OCabM-0000t3-TY; Thu, 13 May 2010 08:45:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Thu, 13 May 2010 15:45:32 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/24#comment:2 Message-ID: <064.64bb68e6b5c58239b9c2989a480828c5@tools.ietf.org> References: <055.3e06cbe3d0929bb0b64fd4bd0b090661@tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <055.3e06cbe3d0929bb0b64fd4bd0b090661@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, jpv@cisco.com, roll@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: roll@ietf.org Subject: Re: [Roll] [roll] #24: Discussion P2P X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 15:46:01 -0000 #24: Discussion P2P -----------------------------------+---------------------------------------- Reporter: jpv@… | Owner: pal@… Type: task | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Candidate WG Document | Keywords: -----------------------------------+---------------------------------------- Changes (by jpv@…): * owner: abr@… => pal@… -- Ticket URL: roll From trac@tools.ietf.org Thu May 13 08:47:39 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC0C3A68E1 for ; Thu, 13 May 2010 08:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.203, 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 TOtlEspf96PK for ; Thu, 13 May 2010 08:47:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F17EC3A6877 for ; Thu, 13 May 2010 08:47:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OCadF-0007RY-Fs; Thu, 13 May 2010 08:47:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Thu, 13 May 2010 15:47:29 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/33#comment:1 Message-ID: <064.37ba91a178465f5b7e0b6ff2ab45bc0b@tools.ietf.org> References: <055.1156abc194de723b97c62420ddb8fc0f@tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <055.1156abc194de723b97c62420ddb8fc0f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@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: roll@ietf.org Subject: Re: [Roll] [roll] #33: Source Route Failure ticket X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 15:47:39 -0000 #33: Source Route Failure ticket -----------------------------------+---------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: new Priority: major | Milestone: Component: building-routing-reqs | Version: Severity: Active WG Document | Keywords: -----------------------------------+---------------------------------------- Changes (by jpv@…): * owner: jhui@… => jpv@… -- Ticket URL: roll From trac@tools.ietf.org Thu May 13 09:20:46 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE653A691A for ; Thu, 13 May 2010 09:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.202, 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 ACo8jPm+A43k for ; Thu, 13 May 2010 09:20:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 347163A6B7F for ; Thu, 13 May 2010 09:20:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OCb9F-0003di-Jo; Thu, 13 May 2010 09:20:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: jhui@archrock.com, jpv@cisco.com X-Trac-Project: roll Date: Thu, 13 May 2010 16:20:33 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/35 Message-ID: <055.4709bbb12e702486b1a753a3ae3db9c6@tools.ietf.org> X-Trac-Ticket-ID: 35 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jhui@archrock.com, jpv@cisco.com, roll@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: roll@ietf.org Subject: [Roll] [roll] #35: Routing Header for source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 16:20:46 -0000 #35: Routing Header for source routing --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jhui@… Type: task | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Source routing is required to support downward routing in RPL configurations where nodes do not maintain downward state. While Routing Header 0 has been deprecated for security reasons, it's format is sound. The proposal is to create a new routing header type that maintains the format of RH0 but with the following additional constraints: - Use of the routing header MUST remain within a RPL domain. The routing header MUST be removed from any datagrams existing a RPL domain. - The routing header MUST be bounded to avoid path MTU issues. We will need to pick what that bound is. -- Ticket URL: roll From pthubert@cisco.com Thu May 13 09:49:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492023A6C5A for ; Thu, 13 May 2010 09:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.567 X-Spam-Level: X-Spam-Status: No, score=-7.567 tagged_above=-999 required=5 tests=[AWL=0.432, 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 ac81fslfn79g for ; Thu, 13 May 2010 09:49:40 -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 133EA3A6C44 for ; Thu, 13 May 2010 09:49:40 -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: AvsEAA7L60urR7Hu/2dsb2JhbACeIXGkEpk6hRIE X-IronPort-AV: E=Sophos;i="4.53,223,1272844800"; d="scan'208";a="129316639" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 13 May 2010 16:49:30 +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 o4DGmuIV008379 for ; Thu, 13 May 2010 16:49:30 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, 13 May 2010 18:49:24 +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, 13 May 2010 18:49:22 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01DF4E75@XMB-AMS-107.cisco.com> In-Reply-To: <731069.44982.qm@web1206.biz.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] closing on #27: DAO ACK ? Thread-Index: AcrtPmBrsVoXZ9yARK6Ns7U6+VfQsAFfYspQ References: <6A2A459175DABE4BB11DE2026AA50A5D01CD834D@XMB-AMS-107.cisco.com> <87y6fxyzjt.fsf@kelsey-ws.hq.ember.com> <731069.44982.qm@web1206.biz.mail.gq1.yahoo.com> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 13 May 2010 16:49:24.0475 (UTC) FILETIME=[3E327CB0:01CAF2BC] Subject: Re: [Roll] closing on #27: DAO ACK ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 16:49:41 -0000 Thanks you all This poll only got positive answers. I asked the authors and got no negative either.=20 Let's include a DAO Ack in 08 then. Hopefully that's very soon. Pascal > -----Original Message----- > From: Roger Alexander [mailto:roger.alexander@ekasystems.com] > Sent: Thursday, May 06, 2010 7:06 PM > To: Richard Kelsey; Pascal Thubert (pthubert) > Cc: roll@ietf.org > Subject: Re: [Roll] closing on #27: DAO ACK ? >=20 > Hi Richard, >=20 >=20 > I think your vote should be considered a win. >=20 > Roger >=20 >=20 > ----- Original Message ---- > From: Richard Kelsey > To: Pascal Thubert (pthubert) > Cc: roll@ietf.org > Sent: Thu, May 6, 2010 8:39:34 AM > Subject: Re: [Roll] closing on #27: DAO ACK ? >=20 > > Date: Mon, 3 May 2010 08:45:25 +0200 > > From: "Pascal Thubert (pthubert)" > > > > As you know, the main problem addressed by ticket 27 is the delay > > caused by loss of DAO. > > > > I've seen a few voices with a general support for the mechanism, but > > not enough to declare a consensus IMHO. > > > > At this point what we can do is: > > > > 1) Reject; no ack for the time being > > > > 2) Adopt, all nodes need to support it. DAO ack request would be an > > optional flag in the DAO. > > > > 3) Make it optional controlled by the root so a node can only join > > a network as a router if it can ACK DAOs. > > > > Please give us a feeling of the WG intention here by voting 1, 2 or 3 > > this week! >=20 > I think we need a way to ACK DAOs (these are lossy networks, after all) but I > am not sure that we need an explicit DAO ACK. >=20 > [RA] These are lossy networks that can have reliable link layer transfers. > Nonetheless, what is considered from the perspective of the RPL protocol is > an acknowledgment between the routing (control) entities. In the case of > the DAO, this acknowledgment can serve the purpose of confirming the > downward routing state between RPL entities. It is in this regard that I favor > an explicit DAO ACK. >=20 > Without local DAO caches ACKs are crucial, because indivicual DAOs travel > multiple hops. Any source-routed message serves as a DAO ACK. Even if the > most recent DAO has been lost, such a message shows that the root has a > working downward path. >=20 > [RA] Without local DAO caches the communicating (control) RPL entities are > the originating node and the root. However, a DAO Parent(s) has to be > participating on behalf of a node to ensure that a downward route can be > derived to the node. Without DAO ACKs the RPL exchanges between these > participating entities (node, DAO Parent(s), root) are all implicit. >=20 >=20 > With local DAO caches, individual DAOs travel only one hop, making them > more reliable. On the other hand, receiving a downward message does not > function as a DAO ACK, because it does not show that the parent has the > complete current DAO. >=20 > [RA] Agreed. In the case of caching nodes the communicating RPL entities are > the node and its DAO Parent(s). In this case the model should be one of > explicitly acknowledged DAO exchanges. >=20 > My preference would be a variant of 2): >=20 > - Without DAO caches, treat downward source-routed messages > as DAO ACKs. DAOs should be retried at some low rate > until an ACK is heard. >=20 > - With DAO caches, have an explicit DAO ACK that is > required. In the interests of simplicity, I would make > sending a DAO ACK required, with no ACK request flag in > the DAO. >=20 > [RA] In the interest of simplicity and compactness I do favor requiring the > DAO to be explicitly ACKed without a flag. I support Richard's suggestion of > tying the capability to the caching/non-caching mode of operation. >=20 > If no one else votes, do I win? >=20 > -Richard Kelsey >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Thu May 13 11:38:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5235F3A67E9 for ; Thu, 13 May 2010 11:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.966 X-Spam-Level: X-Spam-Status: No, score=-4.966 tagged_above=-999 required=5 tests=[AWL=-0.967, 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 04TBcTFM97Uy for ; Thu, 13 May 2010 11:38:32 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id C33063A684F for ; Thu, 13 May 2010 11:38:31 -0700 (PDT) Received: from dn0a208a2b.sunet ([10.32.138.43]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OCdIc-0007LW-3g; Thu, 13 May 2010 11:38:22 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Thu, 13 May 2010 10:48:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1078) X-Scan-Signature: b0d2d5ababd8fe43140185de29a9e1cb Cc: charliep , roll Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 18:38:33 -0000 On Apr 28, 2010, at 10:46 AM, Mukul Goyal wrote: > Hi all >=20 > The following draft has been submitted for WG's consideration. It = describes the additional mechanisms required to support P2P routing in = LLNs. The draft first provides a high level description of the = mechanisms and then proposes one way of realizing these mechanisms in = RPL. >=20 > Regards > Mukul Mukul, I read over p2p-rpl-00. Overall, I think the proposal is sensible. It's = clear from the home automation requirements that RPL needs to be able to = quickly repair/discover routes. This draft suggests a simple way RPL can = support such functionality. The basic mechanism is similar to = AODV/DYMO/DSR, which makes sense. The core ideas in all of the protocols = are sound, we just need to be careful with the details. I have two major = questions: 1) Why are there special measurement packets? This seems to come out of = the required functionality section, but I don't understand its original = seed. Typically, network and/or route measurement are management = concerns and are handled there, rather than inside a routing protocol. = This seems like the wrong place to accomplish the goal. 2) The mechanisms for discovering/establishing "good enough" routes are = a bit vague. 3.2 basically says that nodes use an AODV/DSR/DYMO-like = mechanism, with the caveat that the goal is "good enough" rather than = optimal. But, as is always with such things, the devil is in the = details. For example, when a node sends a discovery messages, who can = forward it? If we say that *any* node can forward it, we're in dangerous = territory; if we say that a node must have the sender in its neighbor = set, then things look a lot better (it means there are link estimates = and we avoid the AODV hopcount problem). Can you be more specific on = what the discovery forwarding algorithm is? Nits: 4.7 says "To facilitate the use of a DIO as the Discovery message, we = suggest the creation of a new "Route Discovery" option that each = DIO/Discovery message must carry." I assume this means:=20 "We suggest the creation of a new "Route Discovery" option that a DIO = message may carry. Inclusion of this option allows a DIO to act as a = Route Discovery message." Otherwise every DIO has to have this option? 4.7 seems to suggest that any node forwards a Route Discovery; I think = this is problematic (see 2 above). Phil= From prvs=743053c1c=mukul@uwm.edu Thu May 13 22:06:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4CAB3A67A1 for ; Thu, 13 May 2010 22:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[AWL=-0.032, 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 g6KXWyriwNfl for ; Thu, 13 May 2010 22:06:43 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 7E81C3A6866 for ; Thu, 13 May 2010 22:06:42 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 14 May 2010 00:06:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 8243D2C38011; Fri, 14 May 2010 00:06:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4N6tNO4z61d0; Fri, 14 May 2010 00:06:32 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 4F5EF2C38013; Fri, 14 May 2010 00:06:32 -0500 (CDT) Date: Fri, 14 May 2010 00:06:32 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1509269043.10942731273813592222.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <533067742.10942441273813466070.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: charliep , roll Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 05:06:45 -0000 Hi Philip, [Philip] I read over p2p-rpl-00. Overall, I think the proposal is sensible. It's clear from the home automation requirements that RPL needs to be able to quickly repair/discover routes. This draft suggests a simple way RPL can support such functionality. The basic mechanism is similar to AODV/DYMO/DSR, which makes sense. The core ideas in all of the protocols are sound, we just need to be careful with the details. I have two major questions: 1) Why are there special measurement packets? This seems to come out of the required functionality section, but I don't understand its original seed. Typically, network and/or route measurement are management concerns and are handled there, rather than inside a routing protocol. This seems like the wrong place to accomplish the goal. [Mukul] The intent of p2p-rpl draft is to present the high level description of required P2P functionality. We do not insist that all the functionality be provided within RPL specs. Applications do need a way to measure the "cost" of an existing route. Such cost measurement helps a node decide whether to initiate a P2P route discovery. I guess such a mechanism can also help decide whether additional permanent DAGs are required. I agree with you that RPL specs is perhaps not the right place where the measurement packets and mechanism should be defined. But I think that ROLL WG should define such a mechanism (rather than some other WG) because this mechanism is highly dependent on the metrics and the metric container options defined by ROLL WG. [Philip] 2) The mechanisms for discovering/establishing "good enough" routes are a bit vague. 3.2 basically says that nodes use an AODV/DSR/DYMO-like mechanism, with the caveat that the goal is "good enough" rather than optimal. But, as is always with such things, the devil is in the details. For example, when a node sends a discovery messages, who can forward it? If we say that *any* node can forward it, we're in dangerous territory; if we say that a node must have the sender in its neighbor set, then things look a lot better (it means there are link estimates and we avoid the AODV hopcount problem). Can you be more specific on what the discovery forwarding algorithm is? [Mukul] I guess I am not sure what your concern is. Could you please elaborate. I am not clear why could it be dangerous for a node to forward a discovery message. Ofcourse, the direction of the route being discovered and whether a node knows the local values for the routing metrics being used would determine whether a node forwards a discovery message further or not. [Philip] Nits: 4.7 says "To facilitate the use of a DIO as the Discovery message, we suggest the creation of a new "Route Discovery" option that each DIO/Discovery message must carry." I assume this means: "We suggest the creation of a new "Route Discovery" option that a DIO message may carry. Inclusion of this option allows a DIO to act as a Route Discovery message." Otherwise every DIO has to have this option? [Mukul] Right. Your text is much better. We certainly did not mean that every DIO must carry the Route Discovery option. [Philip] 4.7 seems to suggest that any node forwards a Route Discovery; I think this is problematic (see 2 above). [Mukul] I guess I need a little more explanation of the problem. Regards Mukul From jpv@cisco.com Fri May 14 02:26:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187B93A6951 for ; Fri, 14 May 2010 02:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[AWL=-4.208, 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 r9a9EpTOiZeg for ; Fri, 14 May 2010 02:26:47 -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 800B33A6ABD for ; Fri, 14 May 2010 02:25:12 -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: AjoCAAe07EuQ/uCWe2dsb2JhbACBPpw+FQEBFiIGHKMImTqFEAQ X-IronPort-AV: E=Sophos;i="4.53,228,1272844800"; d="scan'208,217";a="7337906" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 14 May 2010 08:46:54 +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 o4E9P0Wn022577; Fri, 14 May 2010 09:25:01 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 May 2010 11:25:00 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 May 2010 11:25:00 +0200 Message-Id: From: JP Vasseur To: "Reddy, Joseph" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-163--830844079 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 May 2010 11:24:59 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 14 May 2010 09:25:00.0090 (UTC) FILETIME=[5365F9A0:01CAF347] Cc: "roll@ietf.org" Subject: Re: [Roll] Feedback from ZigBee interop event X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 09:26:48 -0000 --Apple-Mail-163--830844079 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Joseph, First of all, many thanks for the feed-back. I do not think that you =20 got yet a reply from the WG. So let me open a ticket to make sure that =20= your issues are addressed in the coming revision of the RPL ID. Thanks again, this type of feed-back is quite useful. JP. On Apr 12, 2010, at 11:20 PM, Reddy, Joseph wrote: > > Hi, > > I would like to share some feedback from the recent interop event =20 > held by the ZigBee Alliance that was attended by several 802.15.4 =20 > platform vendors. At this event, the main focus was on testing TCP, =20= > RPL and 6lowpan protocols. > > For the RPL protocol, the DAG formation and data transmission "up" =20 > towards the root were tested successfully among the various =20 > platforms. In addition to the feedback on the exiting spec ( see =20 > below ), the main request is to ensure the spec is quickly updated =20 > with the routing/forwarding for "downwards" paths so we can move =20 > forward with our testing. > > -Regards, Joseph > > > 1. Need clarification on the Rank and DagRank. The root rank has =20 > value of 1 but not clear if that is just the integer part or not. > > 2. In OF0, the values for minRankIncrease and maxRankIncrease take =20 > value of 256 which cannot be represented in the DoDAG config =20 > suboption ( which allows only 1 byte ). This needs to be fixed in =20 > the spec. Also, re-consider if we really need fractional part in the =20= > rank, it doesn=92t seem to be very useful. > > 3. Clarify the IP source address for DIS/DAO packets - should this =20 > be the link local or global address ( or either ) ? > > 4. Need clarification on flowlabel. Currently it is not possible to =20= > implement as defined ( without layer violations ) since a node will =20= > need to know if the next hop is the final destination and if the =20 > previous hop was the originator of the packet=85..current =20 > implementations have removed flow label validation > > 5. Need clarification on the use of the destination prefix. How many =20= > of them can be included in a DIO ? Is this intended to be the prefix =20= > of the 6lowpan or is this a prefix that can be reached by the root =20 > node ( on the wired side ) ? > > 6. Does RPL intend to define messages to allow neighboring nodes to =20= > exchange bidirectional link quality estimates between themselves ? > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-163--830844079 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi = Joseph,

First of all, many thanks for the feed-back. = I do not think that you got yet a reply from the WG. So let me open a = ticket to make sure that your issues are addressed in the coming = revision of the RPL ID.

Thanks again, this type = of feed-back is quite = useful.

JP.

On Apr 12, = 2010, at 11:20 PM, Reddy, Joseph wrote:

 
Hi,
 
I would like to = share some feedback from the recent interop event held by the ZigBee = Alliance that was attended by several 802.15.4 platform vendors. At this = event, the main focus was on testing TCP, RPL and 6lowpan = protocols.
 
For the RPL protocol, the DAG formation and data = transmission "up" towards the root were tested successfully among the = various platforms. In addition to the feedback on the exiting spec ( see = below ), the main request is to ensure the spec is quickly updated with = the routing/forwarding for "downwards" paths so we can move forward with = our testing.
 
-Regards, = Joseph
 
 
1. Need = clarification on the Rank and DagRank. The root rank has value of 1 but = not clear if that is just the integer part or = not.
 
2. In = OF0, the values for minRankIncrease and maxRankIncrease take value of = 256 which cannot be represented in the DoDAG config suboption ( which = allows only 1 byte ). This needs to be fixed in the spec. Also, re-consider if we really need fractional part in the = rank, it doesn=92t seem to be very useful.
 
3. Clarify the IP source address for = DIS/DAO packets - should this be the link local or global address ( or = either ) ?
 
4. = Need clarification on flowlabel. Currently it is not possible = to implement as = defined ( without layer violations ) since a node will need to = know if the next hop is the final destination and if the previous= hop was = the originator of the packet=85..current implementations have removed flow label = validation
 
5. Need = clarification on = the use of the destination prefix. How = many of them can be included in a DIO ? Is this intended to be = the prefix of the 6lowpan or is this a prefix that can be reached by the = root node ( on the wired side ) ?
 
6. Does RPL intend = to define messages to allow neighboring nodes to exchange bidirectional = link quality estimates between themselves ?
 
 
 
 
 
_____________________________________= __________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

= --Apple-Mail-163--830844079-- From trac@tools.ietf.org Fri May 14 02:27:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71E83A6AA2 for ; Fri, 14 May 2010 02:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.075 X-Spam-Level: X-Spam-Status: No, score=-101.075 tagged_above=-999 required=5 tests=[AWL=-1.075, 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 HiIrQ8O++YV3 for ; Fri, 14 May 2010 02:27:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AE2B73A6AA3 for ; Fri, 14 May 2010 02:26:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OCr9v-00062p-NM; Fri, 14 May 2010 02:26:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Fri, 14 May 2010 09:26:19 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/36 Message-ID: <055.eafdb4a018a1e09c375f41955727471a@tools.ietf.org> X-Trac-Ticket-ID: 36 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@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: roll@ietf.org Subject: [Roll] [roll] #36: Feedback from ZigBee interop event X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 09:27:57 -0000 #36: Feedback from ZigBee interop event --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Hi, I would like to share some feedback from the recent interop event held by the ZigBee Alliance that was attended by several 802.15.4 platform vendors. At this event, the main focus was on testing TCP, RPL and 6lowpan protocols. For the RPL protocol, the DAG formation and data transmission "up" towards the root were tested successfully among the various platforms. In addition to the feedback on the exiting spec ( see below ), the main request is to ensure the spec is quickly updated with the routing/forwarding for "downwards" paths so we can move forward with our testing. -Regards, Joseph 1. Need clarification on the Rank and DagRank. The root rank has value of 1 but not clear if that is just the integer part or not. 2. In OF0, the values for minRankIncrease and maxRankIncrease take value of 256 which cannot be represented in the DoDAG config suboption ( which allows only 1 byte ). This needs to be fixed in the spec. Also, re- consider if we really need fractional part in the rank, it doesn’t seem to be very useful. 3. Clarify the IP source address for DIS/DAO packets - should this be the link local or global address ( or either ) ? 4. Need clarification on flowlabel. Currently it is not possible to implement as defined ( without layer violations ) since a node will need to know if the next hop is the final destination and if the previous hop was the originator of the packet…..current implementations have removed flow label validation 5. Need clarification on the use of the destination prefix. How many of them can be included in a DIO ? Is this intended to be the prefix of the 6lowpan or is this a prefix that can be reached by the root node ( on the wired side ) ? 6. Does RPL intend to define messages to allow neighboring nodes to exchange bidirectional link quality estimates between themselves ? -- Ticket URL: roll From jpv@cisco.com Fri May 14 02:31:07 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70733A6AB1 for ; Fri, 14 May 2010 02:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.056 X-Spam-Level: X-Spam-Status: No, score=-8.056 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 FH2B1MeDTI6x for ; Fri, 14 May 2010 02:31:06 -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 2F1303A6AB8 for ; Fri, 14 May 2010 02:30:33 -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: AvsEADK17EurR7Ht/2dsb2JhbACdfHGjDZk6gm4IghoE X-IronPort-AV: E=Sophos;i="4.53,228,1272844800"; d="scan'208";a="197441825" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 14 May 2010 09:30:23 +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 o4E9TmsI021416 for ; Fri, 14 May 2010 09:30:23 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 May 2010 11:30:16 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 May 2010 11:30:16 +0200 Message-Id: From: JP Vasseur To: Navneet Agarwal (navagar) In-Reply-To: <3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 May 2010 11:30:15 +0200 References: <8A977BDC5A7B0E429B0F521E8D6F91EE01C5FCF1@XMB-AMS-103.cisco.com> <3EF472F4AD7D824EA24D3197C56B61DB01184BF3@XMB-BGL-41C.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 14 May 2010 09:30:16.0092 (UTC) FILETIME=[0FC00DC0:01CAF348] Cc: ROLL WG Subject: Re: [Roll] IPSO Interop event - Feed-back welcome X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 09:31:07 -0000 Thanks for the feed-back Navneet. You got a few replies to your queries, still I think that they have not all been addressed (feedback II): do you confirm ? If so, I'll open a ticket. Thanks. JP. On Apr 11, 2010, at 7:21 AM, Navneet Agarwal (navagar) wrote: > Hi: > I have two feedbacks from the router testing perspective. > > Feedback-I: > DAO rank: It seems there very couple of different interpretations for > setting this value. > A. Several implementations were setting the DAO rank to be equal to > the > node rank (value sent in DIO rank). Each node relays this info in the > DAO towards the root. However this does not convey any differentiating > info to the receiving nodes when the DAOs are received thru multiple > paths in order to install the best route. > B. The other implementation was to set the value to 0 (or 1) by the > node > and have the intermediate nodes increment it as the DAO rides up to > the > root. The DAO rank in this case is more of a hop count and the > receiving > nodes can make a decision based on the lowest value received when > installing the DAO route. > Pros: Decision is optimized based on hopcount. Relatively simple. > Cons: Hopcount does not take link cost into account. > C. A third proposal was to set the DAO rank equal to the node rank > and a > link cost in the metric container as each nodes propagates the DAO. > The > receiving nodes would make a decision based on the link cost. > Pros: Decision is optimized based on link cost > Cons: The DAOs would need to carry additional info in the packet > (bigger > DAOs) and more processing needed in the nodes to parse and process. > > I think we need some more details the spec for describing the value to > be set in DAO rank. > > > Feedback-II: > DIO Sequence number: The issue was what should be the initial value of > this field. The spec is not clear on what should be the initial value > set by the root. This has implications at the LBR in reload/reboot > conditions. For example, if the initial value is set to 1 and is > incremented to say 10. When the LBR reloads/reboots, it would start > the > sequence number with 1 but its DIOs will be rejected by the nodes as > having stale sequence number. The LBR can store the sequence in > persistent memory. An easier option could be use 255 as the starting > sequence number. Using this value will make sure that the sequence > number is always valid. > > Comments? > > Thanks > > Regards, > Navneet > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of Mathilde Durvy (mdurvy) >> Sent: Thursday, April 08, 2010 1:46 PM >> To: JP Vasseur >> Cc: ROLL WG >> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome >> >> Dear All, >> >> Following the discussion on the mailing list I just wanted to >> clarify a few things so that we can find the best way to >> interact in the future. >> >> - We were proposed a slot to announce this first interop >> event during the ROLL WG meeting, future events may be >> advertised only on an IPSO web-site if this is preferred by the WG. >> - IPSO is not defining standards. It is organizing interop >> events to ensure that different implementations of the same >> standard do work together. The current status is that you >> have to pay a membership fee to participate in these events >> (and indeed these events take work, prior preparation, and >> money to organize). >> - We understand (at least) some people are still interested >> in interop event feedback. This will be given on individual, >> voluntary, basis by the participants of the interop event. >> >> Best, >> Mathilde >> >> >> -----Original Message----- >> From: JP Vasseur [mailto:jpv@cisco.com] >> Sent: vendredi, 26. mars 2010 03:55 >> To: Mathilde Durvy (mdurvy) >> Cc: ROLL WG >> Subject: IPSO Interop event - Feed-back welcome >> >> Hi, >> >> Just re-enforcing my comments during the ROLL WG meeting ... >> any feed- back from the IPSO interop about any issues that >> you may have found would be extremely useful to continue to >> improve our spec. Feel free to also share good news. >> >> Thanks. >> >> JP. >> From navagar@cisco.com Fri May 14 03:29:27 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC5E3A6AAF for ; Fri, 14 May 2010 03:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.649 X-Spam-Level: X-Spam-Status: No, score=-8.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, 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 1iKbC8ji55JA for ; Fri, 14 May 2010 03:29:26 -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 798DB3A6A62 for ; Fri, 14 May 2010 03:29:23 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,229,1272844800"; d="scan'208,217";a="255873815" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-2.cisco.com with ESMTP; 14 May 2010 10:29:13 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4EATCT7024343; Fri, 14 May 2010 10:29:13 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 May 2010 15:59:12 +0530 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_01CAF350.4B6998F4" Date: Fri, 14 May 2010 15:59:12 +0530 Message-ID: <3EF472F4AD7D824EA24D3197C56B61DB033861@XMB-BGL-41C.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] IPSO Interop event - Feed-back welcome Thread-Index: AcrzSCVlIJ2oGOhoRwS23Ecc6uG/wAACCW07 From: "Navneet Agarwal (navagar)" To: "JP Vasseur" X-OriginalArrivalTime: 14 May 2010 10:29:12.0849 (UTC) FILETIME=[4BD25810:01CAF350] Cc: ROLL WG Subject: Re: [Roll] IPSO Interop event - Feed-back welcome X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 10:29:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF350.4B6998F4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP: Sure,,..pls open a ticket and will followup..appreciate it. Thanks Regards, Navneet (sent from mobile) -----Original Message----- From: JP Vasseur [mailto:jpv@cisco.com] Sent: Friday, May 14, 2010 05:30 PM China Standard Time To: Navneet Agarwal (navagar) Cc: ROLL WG; Mathilde Durvy (mdurvy) Subject: Re: [Roll] IPSO Interop event - Feed-back welcome Thanks for the feed-back Navneet. You got a few replies to your =20 queries, still I think that they have not all been addressed (feedback II): do you confirm ? If =20 so, I'll open a ticket. Thanks. JP. On Apr 11, 2010, at 7:21 AM, Navneet Agarwal (navagar) wrote: > Hi: > I have two feedbacks from the router testing perspective. > > Feedback-I: > DAO rank: It seems there very couple of different interpretations for > setting this value. > A. Several implementations were setting the DAO rank to be equal to =20 > the > node rank (value sent in DIO rank). Each node relays this info in the > DAO towards the root. However this does not convey any differentiating > info to the receiving nodes when the DAOs are received thru multiple > paths in order to install the best route. > B. The other implementation was to set the value to 0 (or 1) by the =20 > node > and have the intermediate nodes increment it as the DAO rides up to =20 > the > root. The DAO rank in this case is more of a hop count and the =20 > receiving > nodes can make a decision based on the lowest value received when > installing the DAO route. > Pros: Decision is optimized based on hopcount. Relatively simple. > Cons: Hopcount does not take link cost into account. > C. A third proposal was to set the DAO rank equal to the node rank =20 > and a > link cost in the metric container as each nodes propagates the DAO. =20 > The > receiving nodes would make a decision based on the link cost. > Pros: Decision is optimized based on link cost > Cons: The DAOs would need to carry additional info in the packet =20 > (bigger > DAOs) and more processing needed in the nodes to parse and process. > > I think we need some more details the spec for describing the value to > be set in DAO rank. > > > Feedback-II: > DIO Sequence number: The issue was what should be the initial value of > this field. The spec is not clear on what should be the initial value > set by the root. This has implications at the LBR in reload/reboot > conditions. For example, if the initial value is set to 1 and is > incremented to say 10. When the LBR reloads/reboots, it would start =20 > the > sequence number with 1 but its DIOs will be rejected by the nodes as > having stale sequence number. The LBR can store the sequence in > persistent memory. An easier option could be use 255 as the starting > sequence number. Using this value will make sure that the sequence > number is always valid. > > Comments? > > Thanks > > Regards, > Navneet > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of Mathilde Durvy (mdurvy) >> Sent: Thursday, April 08, 2010 1:46 PM >> To: JP Vasseur >> Cc: ROLL WG >> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome >> >> Dear All, >> >> Following the discussion on the mailing list I just wanted to >> clarify a few things so that we can find the best way to >> interact in the future. >> >> - We were proposed a slot to announce this first interop >> event during the ROLL WG meeting, future events may be >> advertised only on an IPSO web-site if this is preferred by the WG. >> - IPSO is not defining standards. It is organizing interop >> events to ensure that different implementations of the same >> standard do work together. The current status is that you >> have to pay a membership fee to participate in these events >> (and indeed these events take work, prior preparation, and >> money to organize). >> - We understand (at least) some people are still interested >> in interop event feedback. This will be given on individual, >> voluntary, basis by the participants of the interop event. >> >> Best, >> Mathilde >> >> >> -----Original Message----- >> From: JP Vasseur [mailto:jpv@cisco.com] >> Sent: vendredi, 26. mars 2010 03:55 >> To: Mathilde Durvy (mdurvy) >> Cc: ROLL WG >> Subject: IPSO Interop event - Feed-back welcome >> >> Hi, >> >> Just re-enforcing my comments during the ROLL WG meeting ... >> any feed- back from the IPSO interop about any issues that >> you may have found would be extremely useful to continue to >> improve our spec. Feel free to also share good news. >> >> Thanks. >> >> JP. >> ------_=_NextPart_001_01CAF350.4B6998F4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Roll] IPSO Interop event - Feed-back welcome

Hi JP:
Sure,,..pls open a ticket and will followup..appreciate it.

Thanks

Regards,
Navneet

(sent from mobile)

 -----Original Message-----
From:   JP Vasseur [mailto:jpv@cisco.com]
Sent:   Friday, May 14, 2010 05:30 PM China Standard Time
To:     Navneet Agarwal (navagar)
Cc:     ROLL WG; Mathilde Durvy (mdurvy)
Subject:        Re: [Roll] IPSO = Interop event - Feed-back welcome

Thanks for the feed-back Navneet. You got a few replies to = your 
queries, still I think that
they have not all been addressed (feedback II): do you confirm ? = If 
so, I'll open a ticket.

Thanks.

JP.

On Apr 11, 2010, at 7:21 AM, Navneet Agarwal (navagar) wrote:

> Hi:
> I have two feedbacks from the router testing perspective.
>
> Feedback-I:
> DAO rank: It seems there very couple of different interpretations = for
> setting this value.
> A. Several implementations were setting the DAO rank to be equal = to 
> the
> node rank (value sent in DIO rank). Each node relays this info in = the
> DAO towards the root. However this does not convey any = differentiating
> info to the receiving nodes when the DAOs are received thru = multiple
> paths in order to install the best route.
> B. The other implementation was to set the value to 0 (or 1) by = the 
> node
> and have the intermediate nodes increment it as the DAO rides up = to 
> the
> root. The DAO rank in this case is more of a hop count and = the 
> receiving
> nodes can make a decision based on the lowest value received = when
> installing the DAO route.
> Pros: Decision is optimized based on hopcount. Relatively = simple.
> Cons: Hopcount does not take link cost into account.
> C. A third proposal was to set the DAO rank equal to the node = rank 
> and a
> link cost in the metric container as each nodes propagates the = DAO. 
> The
> receiving nodes would make a decision based on the link cost.
> Pros: Decision is optimized based on link cost
> Cons: The DAOs would need to carry additional info in the = packet 
> (bigger
> DAOs) and more processing needed in the nodes to parse and = process.
>
> I think we need some more details the spec for describing the value = to
> be set in DAO rank.
>
>
> Feedback-II:
> DIO Sequence number: The issue was what should be the initial value = of
> this field. The spec is not clear on what should be the initial = value
> set by the root. This has implications at the LBR in = reload/reboot
> conditions. For example, if the initial value is set to 1 and = is
> incremented to say 10. When the LBR reloads/reboots, it would = start 
> the
> sequence number with 1 but its DIOs will be rejected by the nodes = as
> having stale sequence number. The LBR can store the sequence in
> persistent memory. An easier option could be use 255 as the = starting
> sequence number. Using this value will make sure that the = sequence
> number is always valid.
>
> Comments?
>
> Thanks
>
> Regards,
> Navneet
>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On
>> Behalf Of Mathilde Durvy (mdurvy)
>> Sent: Thursday, April 08, 2010 1:46 PM
>> To: JP Vasseur
>> Cc: ROLL WG
>> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome
>>
>> Dear All,
>>
>> Following the discussion on the mailing list I just wanted = to
>> clarify a few things so that we can find the best way to
>> interact in the future.
>>
>> - We were proposed a slot to announce this first interop
>> event during the ROLL WG meeting, future events may be
>> advertised only on an IPSO web-site if this is preferred by the = WG.
>> - IPSO is not defining standards. It is organizing interop
>> events to ensure that different implementations of the same
>> standard do work together. The current status is that you
>> have to pay a membership fee to participate in these events
>> (and indeed these events take work, prior preparation, and
>> money to organize).
>> - We understand (at least) some people are still interested
>> in interop event feedback. This will be given on = individual,
>> voluntary, basis by the participants of the interop event.
>>
>> Best,
>> Mathilde
>>
>>
>> -----Original Message-----
>> From: JP Vasseur [mailto:jpv@cisco.com]
>> Sent: vendredi, 26. mars 2010 03:55
>> To: Mathilde Durvy (mdurvy)
>> Cc: ROLL WG
>> Subject: IPSO Interop event - Feed-back welcome
>>
>> Hi,
>>
>> Just re-enforcing my comments during the ROLL WG meeting = ...
>> any feed- back from the IPSO interop about any issues that
>> you may have found would be extremely useful to continue to
>> improve our spec. Feel free to also share good news.
>>
>> Thanks.
>>
>> JP.
>>

------_=_NextPart_001_01CAF350.4B6998F4-- From trac@tools.ietf.org Fri May 14 03:55:46 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7D53A6B0D for ; Fri, 14 May 2010 03:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.627 X-Spam-Level: X-Spam-Status: No, score=-101.627 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_05=-1.11, 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 23ipYWbZiNUh for ; Fri, 14 May 2010 03:55:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9A0583A6B05 for ; Fri, 14 May 2010 03:55:45 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OCsYI-0002ch-Av; Fri, 14 May 2010 03:55:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Fri, 14 May 2010 10:55:34 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/37 Message-ID: <055.4c35c3aa28af0141d722f6a3d32db39c@tools.ietf.org> X-Trac-Ticket-ID: 37 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@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: roll@ietf.org Subject: [Roll] [roll] #37: Feed-back fron IPSO interop X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 10:55:46 -0000 #37: Feed-back fron IPSO interop --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- > Feedback-I: > DAO rank: It seems there very couple of different interpretations for > setting this value. > A. Several implementations were setting the DAO rank to be equal to > the > node rank (value sent in DIO rank). Each node relays this info in the > DAO towards the root. However this does not convey any differentiating > info to the receiving nodes when the DAOs are received thru multiple > paths in order to install the best route. > B. The other implementation was to set the value to 0 (or 1) by the > node > and have the intermediate nodes increment it as the DAO rides up to > the > root. The DAO rank in this case is more of a hop count and the > receiving > nodes can make a decision based on the lowest value received when > installing the DAO route. > Pros: Decision is optimized based on hopcount. Relatively simple. > Cons: Hopcount does not take link cost into account. > C. A third proposal was to set the DAO rank equal to the node rank > and a > link cost in the metric container as each nodes propagates the DAO. > The > receiving nodes would make a decision based on the link cost. > Pros: Decision is optimized based on link cost > Cons: The DAOs would need to carry additional info in the packet > (bigger > DAOs) and more processing needed in the nodes to parse and process. > > I think we need some more details the spec for describing the value to > be set in DAO rank. > > > Feedback-II: > DIO Sequence number: The issue was what should be the initial value of > this field. The spec is not clear on what should be the initial value > set by the root. This has implications at the LBR in reload/reboot > conditions. For example, if the initial value is set to 1 and is > incremented to say 10. When the LBR reloads/reboots, it would start > the > sequence number with 1 but its DIOs will be rejected by the nodes as > having stale sequence number. The LBR can store the sequence in > persistent memory. An easier option could be use 255 as the starting > sequence number. Using this value will make sure that the sequence > number is always valid. > > Comments? Navneeet Agarwal -- Ticket URL: roll From trac@tools.ietf.org Fri May 14 04:01:51 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB1C3A69AD for ; Fri, 14 May 2010 04:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=0.229, 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 S53t3rGaHI8e for ; Fri, 14 May 2010 04:01:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BB0113A6991 for ; Fri, 14 May 2010 04:01:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OCseB-0002lw-LQ; Fri, 14 May 2010 04:01:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Fri, 14 May 2010 11:01:39 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/37#comment:1 Message-ID: <064.9168e04e935351ef83dc2056812063bc@tools.ietf.org> References: <055.4c35c3aa28af0141d722f6a3d32db39c@tools.ietf.org> X-Trac-Ticket-ID: 37 In-Reply-To: <055.4c35c3aa28af0141d722f6a3d32db39c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@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: roll@ietf.org Subject: Re: [Roll] [roll] #37: Feed-back fron IPSO interop X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 11:01:51 -0000 #37: Feed-back fron IPSO interop --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: new Priority: minor | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Changes (by jpv@…): * priority: major => minor -- Ticket URL: roll From jpv@cisco.com Fri May 14 10:21:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B42F28C14E for ; Fri, 14 May 2010 10:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.425 X-Spam-Level: X-Spam-Status: No, score=-8.425 tagged_above=-999 required=5 tests=[AWL=0.315, 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 7arH+6m5YNkt for ; Fri, 14 May 2010 10:21:50 -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 400AB28C137 for ; Fri, 14 May 2010 10:20:35 -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: AvsEAB4j7UurRN+K/2dsb2JhbACdfnGkXJk1hRAEjzw X-IronPort-AV: E=Sophos;i="4.53,232,1272844800"; d="scan'208";a="529829782" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 14 May 2010 17:20:26 +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 o4EHKP6a001043; Fri, 14 May 2010 17:20:25 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 May 2010 19:20:24 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 May 2010 19:20:24 +0200 Message-Id: <21175DFE-2090-4FAC-9BCC-FDEBB77D20BA@cisco.com> From: JP Vasseur To: Anders Brandt , "JeongGil Ko (John)" In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A11F@zensys17.zensys.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 May 2010 19:20:23 +0200 References: <6AAA6AEF-11B3-4342-BEA3-6D6D39E8154C@cs.jhu.edu> <6D9687E95918C04A8B30A7D6DA805A3E0142A11F@zensys17.zensys.local> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 14 May 2010 17:20:24.0282 (UTC) FILETIME=[BD2443A0:01CAF389] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17382.007 X-TM-AS-Result: No--18.663200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] Source Routing Header Format in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 17:21:52 -0000 Hi Anders and John, A ticket has been opened: ticket #35 and Jonathan kindly agreed to drive it with the help of the WG of course. It should be part of the rev-08. Thanks. JP. On May 7, 2010, at 11:33 AM, Anders Brandt wrote: > Hi John > > You are completely right that we should get into that discussion now. > It relates very much to the next phase of our work on P2P support and > reactive discovery for non-storing nodes. > > draft-dt-roll-p2p-rpl-00 provides the basis for this discussion. > If you have specific proposals for source routing support in RPL, > please come forward ;-) > > > - Anders > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of JeongGil Ko (John) >> Sent: Friday, May 07, 2010 08:24 >> To: ROLL WG >> Subject: [Roll] Source Routing Header Format >> >> Hi all, >> >> Have we decided on what the routing header format will be for >> point-to-point routing? >> The last discussion that I remember concluded with "Let's do >> something like RH0 and do tag/labels for addressing". >> Do we have anything else after that? >> >> -John >> >> ------ >> JeongGil Ko (John) >> Ph.D. Student >> Department of Computer Science >> Johns Hopkins University >> http://www.cs.jhu.edu/~jgko >> >> _______________________________________________ >> 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 jpv@cisco.com Fri May 14 10:26:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E6D28C130 for ; Fri, 14 May 2010 10:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.158 X-Spam-Level: X-Spam-Status: No, score=-8.158 tagged_above=-999 required=5 tests=[AWL=0.027, 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 uK0ffc0Hw5aK for ; Fri, 14 May 2010 10:26:08 -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 947D228C157 for ; Fri, 14 May 2010 10:24:46 -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: Ak0BAEsk7UuQ/uCWe2dsb2JhbACdfhUBARYiBhykYZk1hRAE X-IronPort-AV: E=Sophos;i="4.53,232,1272844800"; d="scan'208";a="61311549" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 May 2010 17:24: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 o4EHOYSn028145; Fri, 14 May 2010 17:24:34 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 May 2010 19:24:34 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 May 2010 19:24:33 +0200 Message-Id: <456B1C27-A563-4AAA-9A9C-D1D93C96BEB7@cisco.com> From: JP Vasseur To: Thomas Herbst In-Reply-To: <485AF6ECE8D1954D996771CC49E996FDC0FE2B21@IT-EXMB-01.silverspringnet.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 May 2010 19:24:33 +0200 References: <485AF6ECE8D1954D996771CC49E996FDC0FE2B21@IT-EXMB-01.silverspringnet.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 14 May 2010 17:24:34.0143 (UTC) FILETIME=[521206F0:01CAF38A] Cc: ROLL WG Subject: Re: [Roll] downward routing? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 17:26:10 -0000 Hi Tom, On May 13, 2010, at 1:39 AM, Thomas Herbst wrote: > Haven't seen anything on this for almost a month. > > Is there progress on some flavor of hop-by-hop or source routing > downward from the DAG Root? > Routing from the root is already supported thanks to the DAO as you know (by the way, the new agreed DAO mechanism will be incorporated with the coming rev-08 (along with Security, P2P, ...)). As far as source routing is concerned, this is also an item for rev08. > RH0 going once, going twice...? > Right, since deprecated, it will more than like be a RH0-like, opened ticket is #35. Thanks. JP. > Tom > > ----------------------------------------------------------------------------------------- > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP Vasseur > Sent: Thursday, April 15, 2010 6:01 AM > To: d.sturek@att.net > Cc: roll@ietf.org > Subject: Re: [Roll] Proposal for Source RoutingHeader Format and > SourceRoutingOperations > > Also my reading (again, co-chair hat off). > > On Apr 15, 2010, at 2:48 PM, Don Sturek wrote: > > > Hi Pascal, > > I believe what you wrote below was the majority view on the reflector. > > Don > > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Thursday, April 15, 2010 5:35 AM > To: JP Vasseur; d.sturek@att.net > Cc: roll@ietf.org > Subject: RE: [Roll] Proposal for Source RoutingHeader Format and > SourceRoutingOperations > > Hi JP and all; > > I'm not fully clear what the WG group really wants to do at this > point. I sensed an agreement to endorse something very close to IPv6 > RH0 in the core spec, and provide a separate spec that would enable > labels in the Source route DAO and the hop by hop header. > > Is that a honest reading of the mailing list? > > Pascal > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP Vasseur > Sent: Thursday, April 15, 2010 2:26 PM > To: d.sturek@att.net > Cc: roll@ietf.org > Subject: Re: [Roll] Proposal for Source RoutingHeader Format and > SourceRoutingOperations > > Hi Don, > > On Apr 8, 2010, at 4:59 PM, Don Sturek wrote: > > I think the issue is this: > 1) ROLL cannot meet its charter without source routing > > Absolutely. > > 2) Claiming the feature is now to be addressed in 6LowPAN > seems a bit wrong. ROLL has as its scope MAC/PHYs other than IEEE > 802.15.4. > > You are absolutely right. IPHC is 15.4 specific. This is why the > idea of using a Label a la MPLS would be an interesting approach > IMO. The labe could be locall significant using DAO as a label > distribution mechanism. Completely link layer agnostic. > > JP. > > How are those addressed? > > Don > > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: Thursday, April 08, 2010 7:52 AM > To: d.sturek@att.net > Cc: daniel.gavelle@jennic.com; roll@ietf.org > Subject: Re: [Roll] Proposal for Source Routing Header Format and > SourceRoutingOperations > > Hi Don, > > It's not so much that 6lowpan is concerning itself with source > routing, it is concerning itself with efficient header compression, > which would include IPv6 extension headers such as RH0. Whatever > ends up getting used for source routing needs to be some sort of > IPv6 extension header. Source routing for IPv6 would naturally > contain IPv6 addresses. The question is whether we want to invent > some new extension header specifically for ROLL which uses something > other (i.e. smaller) than IPv6 addresses, e.g. the tag scheme > mentioned. > > I agree, ROLL must accommodate source routing one way or another. > > Robert > Robert Cragie (Pacific Gas & Electric) > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > On 08/04/2010 2:35 PM, Don Sturek wrote: > I can't see why 6LowPAN (and specifically the HC draft) would > concern itself with source routing. > > Surely source routing is a concern of ROLL (and not 6LowPAN). > > I don't see how ROLL completes its charter or addresses its > requirements without adding source routing. > > Don > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of Daniel Gavelle > Sent: Thursday, April 08, 2010 6:12 AM > To: robert.cragie@gridmerge.com > Cc: roll@ietf.org > Subject: Re: [Roll] Proposal for Source Routing Header Format and > SourceRoutingOperations > > Rob, > > I agree that the source routing for the data frames should be done > as part of the 6LowPAN HC. This already has a stateful IPV6 address > compression based on contexts. It should be possible to compress > the addresses down to two bytes per address if IPv6 addresses are > derived from the 16 bit short address are being used in the LowPAN. > > We don't want to hold up the current HC draft that is going through > last call but the work could be done as a new RFC / amendment. > Source routing compression may need a fix for the problem of HC > compression extending beyond the first fragment. > > Doing the work in the 6LowPAN group means that the compression can > easily be used for any source routing protocol, not just ROLL. It > could be done as a compression for the existing R0 routing header. > Maybe this thread needs moving to the 6LowPAN reflector. > > Daniel. > > > Robert Cragie wrote: > > Hi Pascal, > > Source routing should of course use the IPv6 addresses which means a > lot of overhead for certain underlying link layers, e.g. 802.15.4. I > think it is generally cleaner to do the compression at a layer which > may require it only, e.g. define it in the 6lowpan HC. This is then > free to some extent to specify how the compression is done. Although > I doubt this would go down well in the 6lowpan WG... > > The tag scheme would work but it specifically scopes the source > routing to nodes which operate the scheme. This is probably > acceptable practically but doesn't 'smell right' somehow. > > With regard to the original proposal: it is probably necessary to > carry the full source route all the way to at least the penultimate > node and use an index to show the current position in the route for > potential backtrace and error reporting back along the same route > (assuming link symmetry). This is how RH0 works. > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > > On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote: > > Hi Daniel: > > Routers might have multiple interfaces of multiple MAC types. > Internet 0 even has a MAC-less format. > So the result of you proposal, which looks like a great idea in a pure > 802.15.4 world with short addresses, becomes a nightmare to define > in a fully generic fashion. > > OTOH, a locally significant opaque tag in which the parent could > hide a short address of the child - if it cares to do it that way - > looks like a way more acceptable approach > > So it seems to me that you can get what you want as long as we can > make the tag big enough for short addresses. When the tag is too > small to contain what the parent really needs, then the parent will > have to store a state with the full information in memory, and then > place an index of some sort in the tag. > > What do you think? > > Pascal > > > > > -----Original Message----- > From: Popa, Daniel [mailto:Daniel.Popa@itron.com] > Sent: Thursday, April 08, 2010 11:40 AM > To: ROLL WG > Cc: Pascal Thubert (pthubert); JeongGil Ko (John) > Subject: RE: [Roll] Proposal for Source Routing Header Format and > SourceRoutingOperations > > Hi Pascal, John, > > Since source routing explicitly gives forwarding instruction to each > intermediate node, it can make sense to use only (MAC address based) > > > L2 > > > forwarding instead of (IPv6 address based) L3 forwarding. > > This brings two advantages: > - avoid processing each transit packets up to L3. > - use MAC addresses that - in ROLL environment - have inherently > > > shorter > > > length than an IPv6 address. > > Cheers, > Daniel > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > > Of > > > Pascal Thubert (pthubert) > Sent: jeudi 8 avril 2010 11:15 > To: JeongGil Ko (John); ROLL WG > Subject: Re: [Roll] Proposal for Source Routing Header Format and > SourceRoutingOperations > > Hi John: > > IPv6 already has a number of routing headers, in particular RH0, > > > though it is > > > being deprecated for general use in the Internet. > And there are reasons why the fields in RH0/1 are there and we need > to make sure we lose none of that. In particular a RH is > recoverable, and > > > it is > > > easy to spot the consumed entries. > > On top of this our new problems are: > - make sure the RH stays within the RPL network (since it is used > > > downwards > > > that should be doable) > - control the size (that probably means compress) > > Cheers, > > Pascal > > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > > Of > > > JeongGil Ko (John) > Sent: Wednesday, April 07, 2010 10:05 PM > To: ROLL WG > Subject: [Roll] Proposal for Source Routing Header Format and Source > RoutingOperations > > Hi! > > Great to see all this discussions on downwards route establishment! > > > To > > > add > > > one more to the conversations here is a proposal for source routing > > > headers. > > > In non-storing mode (where only the root has individual path > > > information) > > > the root will be attaching a source routing header to the data > > > packet > > > that a > > > source node wants to send to a specific destination. We can always > > > make the > > > header super fancy but in my opinion I think we only need two fields > > > in this > > > header and here it is! Feel free to break the stuff and mangle with > > > it > > > so that it > > > looks great in the specs later on. FYI, this is the format that I am > > > using in my > > > implementations so it does work :) > > 1. Source Routing Header Format > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NEntry (8 bits) | > > > | > > > +-+-+-+-+-+-+-+-+ > > > + > > > | Source Route Entry (128*NEntry bits) > > > | > > > + > > > + > > > | > > > | > > > Figure 1. Proposed Source Routing Header Format; each line is > > > 32 > > > bits:) > > > - NEntry: Indicates the number of 128 bit addresses that the source > > > route > > > entry field is carrying. > > - Source Route Entry: List of 128 bit address that consist the route > > > to the > > > destination. Here, the address of the node that is one hop away from > > > the > > > *destination* comes first. > > 2. Source Routing Packet Operations > > When source routing is initiated at a storing node (e.g., root of > > > the > > > DODAG), > > > the header is attached on the data packet for the entire route > > > (i.e., > > > from > > > next hop node to the destination). This header is positioned in > > > front > > > of the > > > user payload. When the next hop node receives a packet that is not > > > destined > > > to itself AND the network is NOT provisioned to be in 'storing mode' > > > then it > > > checks NEntry to find what the next hop is in the source route > > > entry. > > > Since > > > the 'Source Route Entry' is ordered in 'farthest -> closest' (in > > > terms > > > of hops) > > > order, a node can figure out what the next hop address is with only > > > the > > > NEntry value (since it already knows how big an ipv6 address is). > > > After > > > collecting the next hop node's address, the node erases this address > element from the entry and decreases NEntry by one. This assures > > > that > > > we > > > avoid the overhead of carrying the entire source route throughout > > > the > > > data > > > path. > > The approach itself should be very simple and trivial for everyone > > > to > > > follow. > > > So we can start from here and build on! > > Thanks. > > -John > > ------ > JeongGil Ko (John) > Ph.D. Student > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko > > _______________________________________________ > 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 > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Sun May 16 23:13:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94B513A6CFD for ; Sun, 16 May 2010 23:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.875 X-Spam-Level: X-Spam-Status: No, score=-8.875 tagged_above=-999 required=5 tests=[AWL=1.724, 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 l-4xaZNrvo0L for ; Sun, 16 May 2010 23:13:34 -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 872AF3A67B5 for ; Sun, 16 May 2010 23:13:33 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,245,1272844800"; d="scan'208";a="61389389" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 17 May 2010 06:13:23 +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 o4H6DNis008944; Mon, 17 May 2010 06:13:23 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, 17 May 2010 08:13:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 17 May 2010 08:13:22 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01E857F4@XMB-AMS-107.cisco.com> In-Reply-To: <064.9168e04e935351ef83dc2056812063bc@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #37: Feed-back fron IPSO interop Thread-Index: AcrzVNpSieH4fqZpQNu+RvvsZt3oGQCMUK+w References: <055.4c35c3aa28af0141d722f6a3d32db39c@tools.ietf.org> <064.9168e04e935351ef83dc2056812063bc@tools.ietf.org> From: "Pascal Thubert (pthubert)" To: , , X-OriginalArrivalTime: 17 May 2010 06:13:23.0208 (UTC) FILETIME=[0DF64080:01CAF588] Subject: Re: [Roll] [roll] #37: Feed-back fron IPSO interop X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 06:13:35 -0000 SGk6DQoNClRoZSBjdXJyZW50IHByb3Bvc2FsIGFzIGRpc2N1c3NlZCBvbiB0aGlzIGxpc3QgaXMg dG8gZHJvcCB0aGUgREFPIHJhbmsuIEluc3RlYWQsIHdlIGhhdmUgYSBwcm9wb3NhbCB0aGF0IHV0 aWxpemVzIHRoZSBwcmVmZXJlbmNlIGluIHN0YXRlbGVzcywgYW5kIGNvbWJpbmVzIHdpdGggYSBm YW5vdXQgY29udHJvbCBiaXRtYXAgaW4gc3RhdGVmdWwuDQpDb21tZW50cyB3b3VsZCBiZSB3ZWxj b21lLCBpbiBwYXJ0aWN1bGFyIFdSVCB0aGUgZmFuLW91dCBjb250cm9sIG1lY2hhbmlzbS4NCg0K UGFzY2FsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcm9sbC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg cm9sbA0KPiBpc3N1ZSB0cmFja2VyDQo+IFNlbnQ6IEZyaWRheSwgTWF5IDE0LCAyMDEwIDE6MDIg UE0NCj4gVG86IHdpbnRlcnRAYWNtLm9yZzsganB2QGNpc2NvLmNvbQ0KPiBDYzogcm9sbEBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1JvbGxdIFtyb2xsXSAjMzc6IEZlZWQtYmFjayBmcm9uIElQ U08gaW50ZXJvcA0KPiANCj4gIzM3OiBGZWVkLWJhY2sgZnJvbiBJUFNPIGludGVyb3ANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiAgUmVwb3J0ZXI6ICBqcHZA4oCmICAgICAgICAgICAgICAgfCAg ICAgICBPd25lcjogIHB0aHViZXJ0QOKApg0KPiAgICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAg ICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCj4gIFByaW9yaXR5OiAgbWlub3IgICAgICAgICAgICAg ICB8ICAgTWlsZXN0b25lOg0KPiBDb21wb25lbnQ6ICBycGwgICAgICAgICAgICAgICAgIHwgICAg IFZlcnNpb246DQo+ICBTZXZlcml0eTogIEFjdGl2ZSBXRyBEb2N1bWVudCAgfCAgICBLZXl3b3Jk czoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDaGFuZ2VzIChieSBqcHZA4oCmKToNCj4gDQo+ ICAgKiBwcmlvcml0eTogIG1ham9yID0+IG1pbm9yDQo+IA0KPiANCj4gLS0NCj4gVGlja2V0IFVS TDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3JvbGwvdHJhYy90aWNrZXQvMzcjY29t bWVudDoxPg0KPiByb2xsIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC8+DQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1h aWxpbmcgbGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcm9sbA0K From abr@sdesigns.dk Mon May 17 00:10:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD8B3A6403 for ; Mon, 17 May 2010 00:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[AWL=-0.272, 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 I+KZ21G8JRK7 for ; Mon, 17 May 2010 00:10:32 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 79A0A3A67FD for ; Mon, 17 May 2010 00:10:32 -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, 17 May 2010 09:10:23 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A14E@zensys17.zensys.local> In-Reply-To: <064.64bb68e6b5c58239b9c2989a480828c5@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #24: Discussion P2P Thread-Index: Acrys2HnAAfJR2f6RDm3GymavCAITQC3B18A References: <055.3e06cbe3d0929bb0b64fd4bd0b090661@tools.ietf.org> <064.64bb68e6b5c58239b9c2989a480828c5@tools.ietf.org> From: "Anders Brandt" To: , , Subject: Re: [Roll] [roll] #24: Discussion P2P X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 07:10:33 -0000 Hello An autonomous P2P team provided a first draft on P2P and we are currently discussing ideas for modified RPL frame formats to support the mechanisms proposed in the draft. Since I was the owner of this ticket I would like to hear the reason for this owner change? Thanks, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of roll issue tracker > Sent: Thursday, May 13, 2010 17:46 > To: pal@cs.stanford.edu; jpv@cisco.com > Cc: roll@ietf.org > Subject: Re: [Roll] [roll] #24: Discussion P2P >=20 > #24: Discussion P2P > -----------------------------------+-------------------------- > ---------- > -----------------------------------+---- > Reporter: jpv@... | Owner: pal@... > Type: task | Status: new =20 > Priority: major | Milestone: =20 > Component: rpl | Version: =20 > Severity: Candidate WG Document | Keywords: =20 > -----------------------------------+-------------------------- > ---------- > -----------------------------------+---- > Changes (by jpv@...): >=20 > * owner: abr@... =3D> pal@... >=20 >=20 > -- > Ticket URL:=20 > > roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From abr@sdesigns.dk Mon May 17 00:29:20 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7B73A67FD for ; Mon, 17 May 2010 00:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=-0.628, 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 4Ux-xF4+jVQ9 for ; Mon, 17 May 2010 00:29:19 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 8F55C3A67B3 for ; Mon, 17 May 2010 00:29:00 -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, 17 May 2010 09:28:52 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A150@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 Thread-Index: Acrm/w6pGpVTCdhwRmicTU+cKuFNRAOkmuJw References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Anders Brandt" To: "roll" Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 07:29:20 -0000 Hi all The P2P draft has been out for some weeks now. The team would like to poll the WG for directions whether this is the right approach. Phil has indicated some agreement. What about the rest of the WG? Others in favour of the work? Any alternative proposals? Otherwise the P2P team will conclude that we are on the right track and go on proposing specific frame format additions/modifications and mechanisms for RPL. When the required maturity is reached, those proposed additions/changes should be adopted by the RPL spec; thus obsoleting this draft. Thanks, Anders > On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote: >=20 > > Hi all > > > > The following draft has been submitted for WG's consideration. It=20 > > describes the additional mechanisms required to support P2P=20 > routing in=20 > > LLNs. The draft first provides a high level description of the=20 > > mechanisms and then proposes one way of realizing these=20 > mechanisms in=20 > > RPL. > > > > Regards > > Mukul > > > > ----- Forwarded Message ----- > > From: "IETF I-D Submission Tool" > > To: mukul@uwm.edu > > Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada=20 > > Central > > Subject: New Version Notification for draft-dt-roll-p2p-rpl-00 > > > > > > A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been=20 > > successfully submitted by Mukul Goyal and posted to the IETF=20 > > repository. > > > > Filename: draft-dt-roll-p2p-rpl > > Revision: 00 > > Title: Mechanisms to Support Point-to-Point=20 > Routing in Low Power =20 > > and Lossy Networks > > Creation_date: 2010-04-28 > > WG ID: Independent Submission > > Number_of_pages: 13 > > > > Abstract: > > This draft presents mechanisms to determine the end-to-end=20 > cost of an=20 > > existing route and to discover/establish "on demand" one or more=20 > > routes between two nodes in a low power and lossy network. =20 > This draft=20 > > also proposes functionality that would enable RPL to=20 > provide these P2P=20 > > mechanisms. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > 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 From jeonggil.ko@gmail.com Mon May 17 00:32:29 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0123A6403 for ; Mon, 17 May 2010 00:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 g3mfiu5o4FMw for ; Mon, 17 May 2010 00:32:27 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 2EDE03A67FD for ; Mon, 17 May 2010 00:32:27 -0700 (PDT) Received: by vws13 with SMTP id 13so3614462vws.31 for ; Mon, 17 May 2010 00:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=w8dYDcdqEa4Qz5dLYwjaCGqsj8+cIRpcML1QJxi0V9s=; b=XLyd1TpbxF8eQ+fx4y0iVjf2xNi64IOEMaGk2+0Z2hcMhl7ov9hntfDUiy5U1FhukV FFOTz3IdjMyBMqwQ1g8qU2A867KDhFWqTopj9cMu5EWEn143sxlXN+sNlKDiNK9FqSX0 wb2zGW5Y5GeMKv8H0IDiNoxgtO8xKGsGHsWSk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=gSljANe2OkfhYIF9elQ6IV2dwTnPYKhyrlGkbi/y6vAAnnmUaDLe85cZk5JKp13TSV c5UJ7fv/JI8fqICgBK4LzDbRPhu05lKHrwS7HVR11tHwzvkBhig3HaO3r0JbdbePkyKd aldmhdBF+aebr/EKLH+2VuO00meyIwWLja2Js= Received: by 10.220.108.198 with SMTP id g6mr2323265vcp.222.1274081536118; Mon, 17 May 2010 00:32:16 -0700 (PDT) Received: from c-68-48-231-220.hsd1.md.comcast.net (c-68-48-231-220.hsd1.md.comcast.net [68.48.231.220]) by mx.google.com with ESMTPS id z17sm24433567vco.17.2010.05.17.00.32.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 May 2010 00:32:14 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "JeongGil Ko (John)" In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A150@zensys17.zensys.local> Date: Mon, 17 May 2010 03:32:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9BB4495F-42C5-4480-AB80-515D44454359@cs.jhu.edu> References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E0142A150@zensys17.zensys.local> To: Anders Brandt X-Mailer: Apple Mail (2.1078) Cc: roll Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 07:32:29 -0000 I also had some concerns and need for clarifications (check previous = emails) but I think it's a nice starting point to get a convergence in = the ideas. -John=20 On May 17, 2010, at 3:28 AM, Anders Brandt wrote: > Hi all >=20 > The P2P draft has been out for some weeks now. > The team would like to poll the WG for directions whether this is > the right approach. >=20 >=20 >=20 > Phil has indicated some agreement. > What about the rest of the WG? >=20 > Others in favour of the work? > Any alternative proposals? >=20 > Otherwise the P2P team will conclude that we are on the right track > and go on proposing specific frame format additions/modifications > and mechanisms for RPL. > When the required maturity is reached, those proposed = additions/changes > should be adopted by the RPL spec; thus obsoleting this draft. >=20 > Thanks, > Anders >=20 >=20 >> On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote: >>=20 >>> Hi all >>>=20 >>> The following draft has been submitted for WG's consideration. It=20 >>> describes the additional mechanisms required to support P2P=20 >> routing in=20 >>> LLNs. The draft first provides a high level description of the=20 >>> mechanisms and then proposes one way of realizing these=20 >> mechanisms in=20 >>> RPL. >>>=20 >>> Regards >>> Mukul >>>=20 >>> ----- Forwarded Message ----- >>> From: "IETF I-D Submission Tool" >>> To: mukul@uwm.edu >>> Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada=20 >>> Central >>> Subject: New Version Notification for draft-dt-roll-p2p-rpl-00 >>>=20 >>>=20 >>> A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been=20 >>> successfully submitted by Mukul Goyal and posted to the IETF=20 >>> repository. >>>=20 >>> Filename: draft-dt-roll-p2p-rpl >>> Revision: 00 >>> Title: Mechanisms to Support Point-to-Point=20 >> Routing in Low Power =20 >>> and Lossy Networks >>> Creation_date: 2010-04-28 >>> WG ID: Independent Submission >>> Number_of_pages: 13 >>>=20 >>> Abstract: >>> This draft presents mechanisms to determine the end-to-end=20 >> cost of an=20 >>> existing route and to discover/establish "on demand" one or more=20 >>> routes between two nodes in a low power and lossy network. =20 >> This draft=20 >>> also proposes functionality that would enable RPL to=20 >> provide these P2P=20 >>> mechanisms. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=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 >>=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From emmanuel.baccelli@gmail.com Mon May 17 01:45:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7891B3A691C for ; Mon, 17 May 2010 01:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.531 X-Spam-Level: X-Spam-Status: No, score=0.531 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 3gAgTzgMh2E4 for ; Mon, 17 May 2010 01:45:34 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 496303A68F8 for ; Mon, 17 May 2010 01:45:28 -0700 (PDT) Received: by wyb42 with SMTP id 42so2394274wyb.31 for ; Mon, 17 May 2010 01:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=ZUoTN2g8ekJyh55FwnxYvzW/5d4+CwAB+X34m1MVzbM=; b=qM76otPOFGkZf66NPS7M+j+qMDi23OcFART3cjbL5q9f1AZZm3J2DKCggkfIuMYIvN vleNgA3v+oRcH7pgIY4yOPlP/+CCNxmHRmTV4iNYPO+OG/EfbC51hcWif3oPhCP2MjEX njRtYdQvUAh867sL86ytoS3wRuT3aVDGoVM0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=IVLcWWafUxhFIXWyqo1QlDf1ly/YaekbGRyqfYeCRCjZeySEmghCGuw9Ahsg/H1/vH HaPDjPf9qSbCk+TKP183Pv9hQLqHZLCgKe0iRxt/l6v7UX2Rczu3RSuN62j0MAqYDYKK KbwMOsSk1rfD4SpfrXQObHd5BZg6BS270mkkA= Received: by 10.216.87.135 with SMTP id y7mr2940883wee.10.1274085917134; Mon, 17 May 2010 01:45:17 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.216.167.139 with HTTP; Mon, 17 May 2010 01:44:57 -0700 (PDT) In-Reply-To: References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu> From: Emmanuel Baccelli Date: Mon, 17 May 2010 10:44:57 +0200 X-Google-Sender-Auth: 3pvOh2mBd9ciYDVyZqZ7PZ5oAp4 Message-ID: To: roll Content-Type: multipart/alternative; boundary=0016e6d7ea7b810fba0486c63e06 Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 08:45:35 -0000 --0016e6d7ea7b810fba0486c63e06 Content-Type: text/plain; charset=ISO-8859-1 Hi Phil, thanks for your feedback. Comments below. On Thu, May 13, 2010 at 7:48 PM, Philip Levis wrote: > > The mechanisms for discovering/establishing "good enough" routes are a bit > vague. 3.2 basically says that nodes use an AODV/DSR/DYMO-like mechanism, > with the caveat that the goal is "good enough" rather than optimal. But, as > is always with such things, the devil is in the details. For example, when a > node sends a discovery messages, who can forward it? If we say that *any* > node can forward it, we're in dangerous territory; if we say that a node > must have the sender in its neighbor set, then things look a lot better (it > means there are link estimates and we avoid the AODV hopcount problem). Can > you be more specific on what the discovery forwarding algorithm is? > > I'm not sure what you are referring to here, but I suppose you are actually asking two different questions here: (1) if any node can forward the discovery messages, how do we make sure that there are no "broadcast storm" or loops? (2) if any node can forward the discovery messages, does it mean it could also be non-related DAGwise (neither parent, nor child)? For now, the draft is more a high level "declaration of intent" than an actual spec, so the answer to question (1) is not yet specified. But of course it will have to be (judging from the amount of experience on this subject in this WG I'm sure it's going to dealt with soon and fine ;). For question (2), the answer is yes: we may need to go along links that are not DAG-related, especially if there is a unique DAG up and running, pointing towards a single access point or sink. In this context, I think I see your concern: if the quality of these links/paths are not monitored properly, how do we now they are good enough? So I agree with you, we need to think about how to monitor and evaluate the quality of these links/paths. This probably means slightly more state maintained in some nodes throughout the network... Do you have any suggestion on how to do this efficiently? I remember you were mentioning some related work in the domain, in Anaheim. Again, the draft is not a spec yet, and just a high level description of some needed functionalities, so any help or suggestion on how to achieve these efficiently is welcome. cheers Emmanuel --0016e6d7ea7b810fba0486c63e06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Phil,
thanks for your feedback. Comments below.=A0


On Thu, May 13, 2010 at 7:48 PM, Philip Levis <pal@cs.stanford.edu>= ; wrote:
=A0

The mechanisms for discovering/establishing "good enough" rou= tes are a bit vague. 3.2 basically says that nodes use an AODV/DSR/DYMO-lik= e mechanism, with the caveat that the goal is "good enough" rathe= r than optimal. But, as is always with such things, the devil is in the det= ails. For example, when a node sends a discovery messages, who can forward = it? If we say that *any* node can forward it, we're in dangerous territ= ory; if we say that a node must have the sender in its neighbor set, then t= hings look a lot better (it means there are link estimates and we avoid the= AODV hopcount problem). Can you be more specific on what the discovery for= warding algorithm is?


I'm not sure what you are referrin= g to here, but I suppose you are actually asking two different questions he= re:=A0
(1) if any node can forward the discovery messages, how do= we make sure that there are no "broadcast storm" or loops?
(2) if any node can forward the=A0discovery messages, does it mean it = could also be non-related DAGwise (neither parent, nor child)?
For now, the draft is more a high level "declaration of i= ntent" than an actual spec, so the answer to question (1) is not yet s= pecified. But of course it will have to be (judging from the amount of expe= rience on this subject in this WG I'm sure it's going to dealt with= soon and fine ;).

For question (2), the answer is yes: we may need to go = along links that are not DAG-related, especially if there is a unique DAG u= p and running, pointing towards a single access point or sink. In this cont= ext, I think I see your concern: if the quality of these links/paths are no= t monitored properly, how do we now they are good enough? So I agree with y= ou, we need to think about how to monitor and evaluate the quality of these= links/paths.=A0

This probably means slightly more state maintained in s= ome nodes throughout the network... Do you have any suggestion on how to do= this efficiently? I remember you were mentioning some related work in the = domain, in Anaheim.=A0Again, the draft is not a spec yet, and just a high l= evel description of some needed functionalities, so any help or suggestion = on how to achieve these=A0efficiently is welcome.

cheers

Emmanuel

=



=A0
--0016e6d7ea7b810fba0486c63e06-- From jpv@cisco.com Mon May 17 05:47:53 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BC93A6B85 for ; Mon, 17 May 2010 05:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.159 X-Spam-Level: X-Spam-Status: No, score=-4.159 tagged_above=-999 required=5 tests=[AWL=-3.974, 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 mHH5kM5kXljC for ; Mon, 17 May 2010 05:47:52 -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 E8CFE3A6C7C for ; Mon, 17 May 2010 05:44:37 -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: Ao8CAKLX8EuQ/uCWe2dsb2JhbACeABUBARYiBhyiMJkWhRAEjzw X-IronPort-AV: E=Sophos;i="4.53,247,1272844800"; d="scan'208";a="7465798" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 17 May 2010 12:06:00 +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 o4HCiMpR016071; Mon, 17 May 2010 12:44:22 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 14:44:22 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 14:44:21 +0200 Message-Id: <7ED5239F-691E-448D-A174-D6B51128584D@cisco.com> From: JP Vasseur To: JeongGil Ko (John) In-Reply-To: <6AAA6AEF-11B3-4342-BEA3-6D6D39E8154C@cs.jhu.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 17 May 2010 14:44:19 +0200 References: <6AAA6AEF-11B3-4342-BEA3-6D6D39E8154C@cs.jhu.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 May 2010 12:44:21.0842 (UTC) FILETIME=[AC65BB20:01CAF5BE] Cc: ROLL WG Subject: Re: [Roll] Source Routing Header Format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 12:47:53 -0000 Hi, On May 7, 2010, at 8:24 AM, JeongGil Ko (John) wrote: > Hi all, > > Have we decided on what the routing header format will be for point- > to-point routing? > The last discussion that I remember concluded with "Let's do > something like RH0 and do tag/labels for addressing". Right, Jonathan agreed to take the ownership of the ticket: indeed the conclusion was RH0-like, staying within RPL domain to avoid security issues. Labels may come next (separate ID). Thanks. JP. > Do we have anything else after that? > > -John > > ------ > JeongGil Ko (John) > Ph.D. Student > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Mon May 17 06:05:06 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2EA33A69BB for ; Mon, 17 May 2010 06:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[AWL=-3.943, 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 EB0siK2HB9LN for ; Mon, 17 May 2010 06:05:05 -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 187473A69F3 for ; Mon, 17 May 2010 06:04:45 -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: Ao8CAFLc8EuQ/uCWe2dsb2JhbACeABUBARYiBhyib5kbhRAEjzw X-IronPort-AV: E=Sophos;i="4.53,247,1272844800"; d="scan'208";a="7467026" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 17 May 2010 12:26:15 +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 o4HD4a9r022235; Mon, 17 May 2010 13:04:37 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 15:04:36 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 15:04:36 +0200 Message-Id: <29BB760E-C09A-4ADB-999F-DE88976E56AF@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <1509269043.10942731273813592222.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 17 May 2010 15:04:35 +0200 References: <1509269043.10942731273813592222.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 May 2010 13:04:36.0421 (UTC) FILETIME=[8057C750:01CAF5C1] Cc: charliep , roll Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 13:05:07 -0000 Hi Mukul, On May 14, 2010, at 7:06 AM, Mukul Goyal wrote: > Hi Philip, > > [Philip] > I read over p2p-rpl-00. Overall, I think the proposal is sensible. > It's clear from the home automation requirements that RPL needs to > be able to quickly repair/discover routes. This draft suggests a > simple way RPL can support such functionality. The basic mechanism > is similar to AODV/DYMO/DSR, which makes sense. The core ideas in > all of the protocols are sound, we just need to be careful with the > details. I have two major questions: > > 1) Why are there special measurement packets? This seems to come out > of the required functionality section, but I don't understand its > original seed. Typically, network and/or route measurement are > management concerns and are handled there, rather than inside a > routing protocol. This seems like the wrong place to accomplish the > goal. > > [Mukul] > The intent of p2p-rpl draft is to present the high level description > of required P2P functionality. We do not insist that all the > functionality be provided within RPL specs. Applications do need a > way to measure the "cost" of an existing route. Such cost > measurement helps a node decide whether to initiate a P2P route > discovery. I guess such a mechanism can also help decide whether > additional permanent DAGs are required. I agree with you that RPL > specs is perhaps not the right place where the measurement packets > and mechanism should be defined. But I think that ROLL WG should > define such a mechanism (rather than some other WG) because this > mechanism is highly dependent on the metrics and the metric > container options defined by ROLL WG. Yes, agree. I would also suggest to make it a separate ID and make use of the routing-metric. You do not need that many modifications to what exist already. Thanks. JP. > > [Philip] > 2) The mechanisms for discovering/establishing "good enough" routes > are a bit vague. 3.2 basically says that nodes use an AODV/DSR/DYMO- > like mechanism, with the caveat that the goal is "good enough" > rather than optimal. But, as is always with such things, the devil > is in the details. For example, when a node sends a discovery > messages, who can forward it? If we say that *any* node can forward > it, we're in dangerous territory; if we say that a node must have > the sender in its neighbor set, then things look a lot better (it > means there are link estimates and we avoid the AODV hopcount > problem). Can you be more specific on what the discovery forwarding > algorithm is? > > [Mukul] > I guess I am not sure what your concern is. Could you please > elaborate. I am not clear why could it be dangerous for a node to > forward a discovery message. Ofcourse, the direction of the route > being discovered and whether a node knows the local values for the > routing metrics being used would determine whether a node forwards a > discovery message further or not. > > [Philip] > Nits: > > 4.7 says "To facilitate the use of a DIO as the Discovery message, > we suggest the creation of a new "Route Discovery" option that each > DIO/Discovery message must carry." I assume this means: > > "We suggest the creation of a new "Route Discovery" option that a > DIO message may carry. Inclusion of this option allows a DIO to act > as a Route Discovery message." > > Otherwise every DIO has to have this option? > > [Mukul] > Right. Your text is much better. We certainly did not mean that > every DIO must carry the Route Discovery option. > > [Philip] > 4.7 seems to suggest that any node forwards a Route Discovery; I > think this is problematic (see 2 above). > > [Mukul] > I guess I need a little more explanation of the problem. > > Regards > Mukul > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Mon May 17 06:05:16 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B812A3A67AB for ; Mon, 17 May 2010 06:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.192 X-Spam-Level: X-Spam-Status: No, score=-8.192 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_20=-0.74, 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 106q1gDni+wS for ; Mon, 17 May 2010 06:05:15 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 195DD3A69A4 for ; Mon, 17 May 2010 06:05:06 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFzc8EurRN+K/2dsb2JhbACeAHGidJkbhRAEjzw X-IronPort-AV: E=Sophos;i="4.53,247,1272844800"; d="scan'208,217";a="222832451" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 17 May 2010 13:04:58 +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 o4HD4vcG014234; Mon, 17 May 2010 13:04:57 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 15:04:55 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 15:04:54 +0200 Message-Id: From: JP Vasseur To: Anders Brandt , Mukul Goyal In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A150@zensys17.zensys.local> Content-Type: multipart/alternative; boundary=Apple-Mail-218--558448716 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 17 May 2010 15:04:54 +0200 References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E0142A150@zensys17.zensys.local> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 May 2010 13:04:55.0124 (UTC) FILETIME=[8B7DA140:01CAF5C1] Cc: roll Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 13:05:16 -0000 --Apple-Mail-218--558448716 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Anders, Co-chair hat-off. I think that it goes in right direction. Few comments for the moment. 1) o The constraint to route only along a DAG leading to significantly suboptimal P2P routes and traffic congestion near the DAG root. JP> You may want to soften the statement here since the path computed along the DAG may be sub-optimal .. it all depends on the destination, degree of meshing of the DAG, etc ... I think that the argument of not having to maintain route maintenance for some nodes is more compelling. 2) Such applications require a mechanism for "reactive route discovery" and the ability to route "across DAGs". JP> Why is it required to route across DAGs ? I guess that you meant "non DAG" routes ? 3) The mechanisms described in this document are intended to be employed as complementary to RPL in specific scenarios that need point-to- point (P2P) routes between arbitrary nodes. JP> More specifically, I think that we agree that it will be part of RPL, as an optional mechanism. 4) Section 4.2: objective function JP> You actually do not need an OF for that. Just use the metrics specified in the Routing-metrics ID, adding a path-cost-bound object (for the "good enough" criteria). 5) 4.6. Transport of Routing Metrics The Metric Container option defined in RPL-07 can be used to carry both the aggregated end-to-end and the local values for the routing metrics being used to define the routing cost. Additional metric objects may need to be defined to carry the aggregated end-to-end routing cost and a source-route unmodified from one node to another; JP> with regards to the second part of the paragraph I would suggest to use the same metrics as defined in the routing-metric ID. 6) We just need to have a section somewhere indicating that such reactive mechanism has a cost too and the resulting path cost decrease is not known a priori and may end up being close to the DAG cost for that destination. I am not questioning the usefulness of the mechanism, just make sure to indicate it. Thanks. JP. On May 17, 2010, at 9:28 AM, Anders Brandt wrote: > Hi all > > The P2P draft has been out for some weeks now. > The team would like to poll the WG for directions whether this is > the right approach. > > > > Phil has indicated some agreement. > What about the rest of the WG? > > Others in favour of the work? > Any alternative proposals? > > Otherwise the P2P team will conclude that we are on the right track > and go on proposing specific frame format additions/modifications > and mechanisms for RPL. > When the required maturity is reached, those proposed additions/ > changes > should be adopted by the RPL spec; thus obsoleting this draft. > > Thanks, > Anders > > >> On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote: >> >>> Hi all >>> >>> The following draft has been submitted for WG's consideration. It >>> describes the additional mechanisms required to support P2P >> routing in >>> LLNs. The draft first provides a high level description of the >>> mechanisms and then proposes one way of realizing these >> mechanisms in >>> RPL. >>> >>> Regards >>> Mukul >>> >>> ----- Forwarded Message ----- >>> From: "IETF I-D Submission Tool" >>> To: mukul@uwm.edu >>> Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada >>> Central >>> Subject: New Version Notification for draft-dt-roll-p2p-rpl-00 >>> >>> >>> A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been >>> successfully submitted by Mukul Goyal and posted to the IETF >>> repository. >>> >>> Filename: draft-dt-roll-p2p-rpl >>> Revision: 00 >>> Title: Mechanisms to Support Point-to-Point >> Routing in Low Power >>> and Lossy Networks >>> Creation_date: 2010-04-28 >>> WG ID: Independent Submission >>> Number_of_pages: 13 >>> >>> Abstract: >>> This draft presents mechanisms to determine the end-to-end >> cost of an >>> existing route and to discover/establish "on demand" one or more >>> routes between two nodes in a low power and lossy network. >> This draft >>> also proposes functionality that would enable RPL to >> provide these P2P >>> mechanisms. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >>> _______________________________________________ >>> 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 --Apple-Mail-218--558448716 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Anders,

Co-chair hat-off.

I = think that it goes in right direction.

Few = comments for the moment.

1)  o The constraint to route only along a DAG leading to = significantly
      suboptimal P2P routes and traffic congestion near the =
DAG root.
JP> You may want to soften the statement here since the = path computed along the DAG 
may be sub-optimal .. it = all depends on the destination, degree of meshing of the DAG, etc = ...
I= think that the argument of not having to maintain route maintenance for = some nodes is 
more compelling.

2)  Such applications require a mechanism for "reactive route = discovery"
   and the ability to route "across DAGs". =

JP> Why is it required to route = across DAGs ? I guess that you meant "non DAG" routes = ?

3) The mechanisms = described in this document are intended to be = employed
   as complementary to RPL in specific =
scenarios that need point-to-
   point (P2P) routes between arbitrary nodes.

JP> More specifically, = I think that we agree that it will be part of RPL, as an optional = mechanism.

4) Section 4.2: objective = function

JP> You actually do not need an OF for that. Just = use the metrics specified in the Routing-metrics = ID,
adding a path-cost-bound object (for the "good = enough" criteria).

5) 4.6. = Transport of Routing Metrics
   The Metric Container option =
defined in RPL-07 can be used to carry
   both the aggregated end-to-end and the local values for the routing
   metrics being used to define the routing cost.  Additional metric
   objects may need to be defined to carry the aggregated end-to-end
   routing cost and a source-route unmodified from one node to =
another;

JP> with regards to the second part of the = paragraph I would suggest to use the same metrics as = defined
in the routing-metric ID.

6) We just need to have a = section somewhere indicating that such reactive mechanism has a cost too = and the resulting
path cost decrease is not known a priori and may end = up being close to the DAG cost for that destination. I am = not
questioning the usefulness of the mechanism, just = make sure to indicate it.

Thanks.

JP.

On May 17, = 2010, at 9:28 AM, Anders Brandt wrote:

Hi = all

The P2P draft has been out for some weeks now.
The team = would like to poll the WG for directions whether this is
the right = approach.



Phil has indicated some agreement.
What = about the rest of the WG?

Others in favour of the work?
Any = alternative proposals?

Otherwise the P2P team will conclude that = we are on the right track
and go on proposing specific frame format = additions/modifications
and mechanisms for RPL.
When the required = maturity is reached, those proposed additions/changes
should be = adopted by the RPL spec; thus obsoleting this draft.

Thanks,
=  Anders


On Apr 28, 2010, at = 7:46 PM, Mukul Goyal wrote:

Hi all

The following draft has been = submitted for WG's consideration. It =
describes the additional mechanisms required to support = P2P
routing in =
LLNs.= The draft first provides a high level description of the =
mechanisms and then proposes one way of realizing these =
mechanisms in =
RPL.

Regards
Mukul

----- Forwarded Message = -----
From: "IETF I-D Submission Tool" <idsubmission@ietf.org>
To: mukul@uwm.edu
Sent: Wednesday, = April 28, 2010 12:40:38 PM GMT -06:00 US/Canada =
Central
Subject: New Version = Notification for = draft-dt-roll-p2p-rpl-00


A new version of I-D, = draft-dt-roll-p2p-rpl-00.txt has been =
successfully submitted by Mukul Goyal and posted to the = IETF
repository.

Filename: = draft-dt-roll-p2p-rpl
Revision: = 00
Title: Mechanisms to Support = Point-to-Point
Routing in Low Power  
and Lossy = Networks
Creation_date: = 2010-04-28
WG ID: = Independent Submission
Number_of_pages: = 13

Abstract:
This draft presents mechanisms = to determine the end-to-end
cost of an
existing route and to = discover/establish "on demand" one or more =
routes between two nodes in a low power and lossy network. =  
This draft =
also = proposes functionality that would enable RPL to =
provide these = P2P
mechanisms.



The IETF = Secretariat.


_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

___________________________________________= ____
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-218--558448716-- From abr@sdesigns.dk Mon May 17 07:21:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E218F3A6A6B for ; Mon, 17 May 2010 07:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[AWL=-0.504, 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 EAFT8uuuFzqc for ; Mon, 17 May 2010 07:21:36 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id D7D963A6CA1 for ; Mon, 17 May 2010 07:18:09 -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_01CAF5CB.C1EEAEB2" Date: Mon, 17 May 2010 16:18:01 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A162@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 Thread-Index: Acr1wY9lvUNMnT1xSbqN0r1Jlad2VgAByutA References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E0142A150@zensys17.zensys.local> From: "Anders Brandt" To: "JP Vasseur" , "Mukul Goyal" Cc: roll Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 14:21:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF5CB.C1EEAEB2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JP =20 Please find comments inline =20 - Anders =20 ________________________________ From: JP Vasseur [mailto:jpv@cisco.com]=20 Sent: Monday, May 17, 2010 15:05 To: Anders Brandt; Mukul Goyal Cc: roll Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 =09 =09 Hi Anders,=20 =09 =09 Co-chair hat-off. =09 =09 I think that it goes in right direction. =09 =09 Few comments for the moment. =09 =09 1) o The constraint to route only along a DAG leading to significantly suboptimal P2P routes and traffic congestion near the DAG root. =09 JP> You may want to soften the statement here since the path computed along the DAG=20 may be sub-optimal .. it all depends on the destination, degree of meshing of the DAG, etc ... I think that the argument of not having to maintain route maintenance for some nodes is=20 more compelling.=20 =20 =09 =09 What about: "The constraint to route only along a DAG potentially leading to significantly suboptimal P2P routes and traffic congestion near the DAG root." ? 2) Such applications require a mechanism for "reactive route discovery" and the ability to route "across DAGs".=20 =09 =09 JP> Why is it required to route across DAGs ? I guess that you meant "non DAG" routes ?=20 =20 Agreed. What the text should say is: "across a DAG", "across the branches of a dag" or "along non-DAG routes" (pick one)=20 3) The mechanisms described in this document are intended to be employed as complementary to RPL in specific scenarios that need point-to- point (P2P) routes between arbitrary nodes. =09 =09 JP> More specifically, I think that we agree that it will be part of RPL, as an optional mechanism.=20 =20 Negative.=20 RPL will never be able to deliver the required performance for home and building without decent support for battery operation and reactive self-healing. =09 4) Section 4.2: objective function =09 =09 JP> You actually do not need an OF for that. Just use the metrics specified in the Routing-metrics ID, adding a path-cost-bound object (for the "good enough" criteria).=20 =20 Great. This is an example of why it will be valuable for RPL as a whole if the WG starts discussing how to achieve the stated goals of the draft. OF or metrics - I leave it for the experts to decide which is the right thing. As long as I can ask for a "good enough" route as result of a reactive discovery. I need the lamp to turn on with low delay. Later, I may have time for fine-tuning the route. =20 =09 5) 4.6. Transport of Routing Metrics The Metric Container option defined in RPL-07 can be used to carry both the aggregated end-to-end and the local values for the routing metrics being used to define the routing cost. Additional metric objects may need to be defined to carry the aggregated end-to-end routing cost and a source-route unmodified from one node to another; =09 =09 JP> with regards to the second part of the paragraph I would suggest to use the same metrics as defined in the routing-metric ID. =09 =09 6) We just need to have a section somewhere indicating that such reactive mechanism has a cost too and the resulting path cost decrease is not known a priori and may end up being close to the DAG cost for that destination. I am not questioning the usefulness of the mechanism, just make sure to indicate it. =09 =09 Thanks. =09 =09 JP. =09 =09 On May 17, 2010, at 9:28 AM, Anders Brandt wrote: Hi all =09 The P2P draft has been out for some weeks now. The team would like to poll the WG for directions whether this is the right approach. =09 =09 =09 Phil has indicated some agreement. What about the rest of the WG? =09 Others in favour of the work? Any alternative proposals? =09 Otherwise the P2P team will conclude that we are on the right track and go on proposing specific frame format additions/modifications and mechanisms for RPL. When the required maturity is reached, those proposed additions/changes should be adopted by the RPL spec; thus obsoleting this draft. =09 Thanks, Anders =09 =09 =09 On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote: =09 Hi all =09 The following draft has been submitted for WG's consideration. It=20 =09 describes the additional mechanisms required to support P2P=20 =09 routing in=20 =09 LLNs. The draft first provides a high level description of the=20 =09 mechanisms and then proposes one way of realizing these=20 =09 mechanisms in=20 =09 RPL. =09 Regards =09 Mukul =09 ----- Forwarded Message ----- =09 From: "IETF I-D Submission Tool" =09 To: mukul@uwm.edu =09 Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada=20 =09 Central =09 Subject: New Version Notification for draft-dt-roll-p2p-rpl-00 =09 A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been=20 =09 successfully submitted by Mukul Goyal and posted to the IETF=20 =09 repository. =09 Filename: draft-dt-roll-p2p-rpl =09 Revision: 00 =09 Title: Mechanisms to Support Point-to-Point=20 =09 Routing in Low Power =20 =09 and Lossy Networks =09 Creation_date: 2010-04-28 =09 WG ID: Independent Submission =09 Number_of_pages: 13 =09 Abstract: =09 This draft presents mechanisms to determine the end-to-end=20 =09 cost of an=20 =09 existing route and to discover/establish "on demand" one or more=20 =09 routes between two nodes in a low power and lossy network. =20 =09 This draft=20 =09 also proposes functionality that would enable RPL to=20 =09 provide these P2P=20 =09 mechanisms. =09 The IETF Secretariat. =09 =09 _______________________________________________ =09 Roll mailing list =09 Roll@ietf.org =09 =09 https://www.ietf.org/mailman/listinfo/roll =09 _______________________________________________ =09 Roll mailing list =09 Roll@ietf.org =09 https://www.ietf.org/mailman/listinfo/roll =09 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =09 ------_=_NextPart_001_01CAF5CB.C1EEAEB2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi JP
 
Please find=20 comments inline
 
-=20 Anders
 

From: JP Vasseur = [mailto:jpv@cisco.com]=20
Sent: Monday, May 17, 2010 15:05
To: Anders = Brandt; Mukul=20 Goyal
Cc: roll
Subject: Re: [Roll] Fwd: New = Version=20 Notification fordraft-dt-roll-p2p-rpl-00

Hi Anders,

Co-chair hat-off.

I think that it goes in right direction.

Few comments for the moment.

1)  o The = constraint to=20 route only along a DAG leading to significantly
      suboptimal P2P routes and traffic =
congestion near the DAG root.
JP> You=20 may want to soften the statement here since the path computed along = the=20 DAG 
may be = sub-optimal .. it all=20 depends on the destination, degree of meshing of the DAG, etc = ...
I think that the = argument of=20 not having to maintain route maintenance for some nodes = is 
more = compelling. 
 

What=20 about:
"The = constraint to route=20 only along a DAG potentially leading to = significantly
suboptimal = P2P routes and=20 traffic congestion near the DAG root."  =20 ?
2)  Such = applications=20 require a mechanism for "reactive route = discovery"
   =
and the ability to route "across DAGs".

JP> Why is it required to route = across DAGs=20 ? I guess that you meant "non DAG" routes ? 
 
Agreed. What the text should say is:
"across a=20 DAG", "across the branches of a dag" or "along non-DAG routes"  = (pick=20 one) 
3) The = mechanisms described=20 in this document are intended to be employed
   as complementary to RPL in specific =
scenarios that need point-to-
   point (P2P) routes between arbitrary nodes.

JP> More = specifically, I=20 think that we agree that it will be part of RPL, as an optional=20 mechanism. 
 
Negative.
RPL=20 will never be able to deliver the required performance for home=20 and
building without decent support for battery operation and = reactive=20 self-healing.
4) Section 4.2: = objective=20 function

JP> You = actually do not=20 need an OF for that. Just use the metrics specified in the = Routing-metrics=20 ID,
adding a = path-cost-bound=20 object (for the "good enough" criteria). 
 
Great.=20 This is an example of why it will be valuable for RPL as a whole if the = WG=20 starts discussing
how to=20 achieve the stated goals of the draft.
OF or=20 metrics - I leave it for the experts to decide which is the right thing. = As long=20 as I can ask for a
"good=20 enough" route as result of a reactive discovery. I need the lamp to turn = on with=20 low delay.
Later,=20 I may have time for fine-tuning the=20 route.
 

5) 4.6. = Transport of=20 Routing Metrics
   The Metric Container option defined in RPL-07 can be used =
to carry
   both the aggregated end-to-end and the local values for the routing
   metrics being used to define the routing cost.  Additional metric
   objects may need to be defined to carry the aggregated end-to-end
   routing cost and a source-route unmodified from one node to =
another;

JP> with = regards to the=20 second part of the paragraph I would suggest to use the same metrics = as=20 defined
in the = routing-metric=20 ID.

6) We just need = to have a=20 section somewhere indicating that such reactive mechanism has a cost = too and=20 the resulting
path cost = decrease is not=20 known a priori and may end up being close to the DAG cost for that=20 destination. I am not
questioning the = usefulness of=20 the mechanism, just make sure to indicate it.

Thanks.

JP.

On May 17,=20 2010, at 9:28 AM, Anders Brandt wrote:

Hi all

The P2P draft has been out for some weeks = now.
The=20 team would like to poll the WG for directions whether this is
the = right=20 approach.



Phil has indicated some agreement.
What = about=20 the rest of the WG?

Others in favour of the work?
Any = alternative=20 proposals?

Otherwise the P2P team will conclude that we are = on the=20 right track
and go on proposing specific frame format=20 additions/modifications
and mechanisms for RPL.
When the = required=20 maturity is reached, those proposed additions/changes
should be = adopted=20 by the RPL spec; thus obsoleting this=20 draft.

Thanks,
 Anders


On Apr 28, 2010, at 7:46 PM, Mukul Goyal=20 wrote:

Hi all

The following draft has been submitted = for WG's=20 consideration. It
describes the additional mechanisms = required to=20 support P2P
routing in
LLNs. The draft first provides a high = level=20 description of the
mechanisms and then proposes one way of=20 realizing these
mechanisms in
RPL.

Regards
Mukul

----- Forwarded Message=20 -----
From: "IETF I-D Submission Tool" <idsubmission@ietf.org>
To: mukul@uwm.edu
Sent: Wednesday, April 28, 2010 12:40:38 = PM GMT=20 -06:00 US/Canada
Central
Subject: New Version Notification for=20 draft-dt-roll-p2p-rpl-00


A new version of I-D,=20 draft-dt-roll-p2p-rpl-00.txt has been =
successfully submitted by Mukul Goyal = and posted=20 to the IETF
repository.

Filename:=20 draft-dt-roll-p2p-rpl
Revision: = 00
Title: Mechanisms to Support = Point-to-Point=20
Routing in Low Power =  
and Lossy = Networks
Creation_date: = 2010-04-28
WG ID: Independent=20 Submission
Number_of_pages: = 13

Abstract:
This draft presents mechanisms to = determine the=20 end-to-end
cost of an
existing route and to discover/establish = "on=20 demand" one or more
routes between two nodes in a low power = and=20 lossy network.  
This draft
also proposes functionality that would = enable=20 RPL to
provide these P2P
mechanisms.



The IETF = Secretariat.


_______________________________________________
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=20 mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

------_=_NextPart_001_01CAF5CB.C1EEAEB2-- From adam@sics.se Mon May 17 09:32:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@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: [Roll] CFP ACM BuildSys 2010, in conjunction with ACM SenSys 2010 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks 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 pal@cs.stanford.edu Mon May 17 09:46:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2697A3A688B for ; Mon, 17 May 2010 09:46:03 -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=-0.913, BAYES_50=0.001, 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 P4aT5vswg-aV for ; Mon, 17 May 2010 09:46:01 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 160BC3A6A60 for ; Mon, 17 May 2010 09:45:50 -0700 (PDT) Received: from dnab404679.stanford.edu ([171.64.70.121]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OE3Rl-0001T4-Lz; Mon, 17 May 2010 09:45:42 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-77--547356553 From: Philip Levis In-Reply-To: Date: Mon, 17 May 2010 09:09:46 -0700 Message-Id: <7C2633B4-4EFD-420A-8EB8-7DEA411D8550@cs.stanford.edu> References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu> To: Emmanuel Baccelli X-Mailer: Apple Mail (2.1078) X-Scan-Signature: 6c8cb0273de1460ab521b985bed8743e Cc: roll Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 16:46:03 -0000 --Apple-Mail-77--547356553 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 17, 2010, at 1:44 AM, Emmanuel Baccelli wrote: >=20 > Hi Phil, > thanks for your feedback. Comments below.=20 >=20 >=20 > On Thu, May 13, 2010 at 7:48 PM, Philip Levis = wrote: > =20 >=20 > The mechanisms for discovering/establishing "good enough" routes are a = bit vague. 3.2 basically says that nodes use an AODV/DSR/DYMO-like = mechanism, with the caveat that the goal is "good enough" rather than = optimal. But, as is always with such things, the devil is in the = details. For example, when a node sends a discovery messages, who can = forward it? If we say that *any* node can forward it, we're in dangerous = territory; if we say that a node must have the sender in its neighbor = set, then things look a lot better (it means there are link estimates = and we avoid the AODV hopcount problem). Can you be more specific on = what the discovery forwarding algorithm is? >=20 >=20 > I'm not sure what you are referring to here, but I suppose you are = actually asking two different questions here:=20 > (1) if any node can forward the discovery messages, how do we make = sure that there are no "broadcast storm" or loops? > (2) if any node can forward the discovery messages, does it mean it = could also be non-related DAGwise (neither parent, nor child)? >=20 > For now, the draft is more a high level "declaration of intent" than = an actual spec, so the answer to question (1) is not yet specified. But = of course it will have to be (judging from the amount of experience on = this subject in this WG I'm sure it's going to dealt with soon and fine = ;). >=20 > For question (2), the answer is yes: we may need to go along links = that are not DAG-related, especially if there is a unique DAG up and = running, pointing towards a single access point or sink. In this = context, I think I see your concern: if the quality of these links/paths = are not monitored properly, how do we now they are good enough? So I = agree with you, we need to think about how to monitor and evaluate the = quality of these links/paths.=20 >=20 > This probably means slightly more state maintained in some nodes = throughout the network... Do you have any suggestion on how to do this = efficiently? I remember you were mentioning some related work in the = domain, in Anaheim. Again, the draft is not a spec yet, and just a high = level description of some needed functionalities, so any help or = suggestion on how to achieve these efficiently is welcome. Actually, it was neither 1 nor 2. :) 1 is a non-starter and there are some known techniques for preventing = it, I assume the actual specification will include them. The one caveat = is that we want to minimize state requirements and avoid things like = sequence number loops (where A > B > C > A for wraparound reasons). I agree with your comment on 2 -- nodes in a P2P route may need to be = neither parents nor children. My concern is a little more subtle.=20 One of the dangers of on-demand mechanisms is that routes are = established quickly, but detecting good links requires time. Node B = receiving a discovery message from node A does not imply that A <-> B = can be included in a workable route. If node B does not have a good = estimate of AB, it should not forward a discovery message after hearing = it from A. Something as simple as saying that a node MUST NOT forward a = discovery message if 1) the transmitter is outside its neighbor set, or 2) the link to/from the transmitter has poor properties (realize this = needs to be more precise). might be sufficient. This is one of those cases where doing the simple and easy thing (just = forward!) has terrible implications. I realize that the current = statement of intent calls for forwarded discovery messages to include = metrics/cost/Rank/etc. What's critical is that receiving a discovery = packet be insufficient for determining this value, because in LLNs it = is. Does that make sense? Phil= --Apple-Mail-77--547356553 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi Phil,
thanks for your feedback. Comments = below. 


On Thu, May = 13, 2010 at 7:48 PM, Philip Levis <pal@cs.stanford.edu> = wrote:
 

The mechanisms for discovering/establishing "good enough" routes are = a bit vague. 3.2 basically says that nodes use an AODV/DSR/DYMO-like = mechanism, with the caveat that the goal is "good enough" rather than = optimal. But, as is always with such things, the devil is in the = details. For example, when a node sends a discovery messages, who can = forward it? If we say that *any* node can forward it, we're in dangerous = territory; if we say that a node must have the sender in its neighbor = set, then things look a lot better (it means there are link estimates = and we avoid the AODV hopcount problem). Can you be more specific on = what the discovery forwarding algorithm is?


I'm not sure what you are referring = to here, but I suppose you are actually asking two different questions = here: 
(1) if any node can forward the discovery = messages, how do we make sure that there are no "broadcast storm" or = loops?
(2) if any node can forward the discovery messages, does it = mean it could also be non-related DAGwise (neither parent, nor = child)?

For now, the draft is more a high level = "declaration of intent" than an actual spec, so the answer to question = (1) is not yet specified. But of course it will have to be (judging from = the amount of experience on this subject in this WG I'm sure it's going = to dealt with soon and fine ;).

For question (2), the answer is yes: we may need to = go along links that are not DAG-related, especially if there is a unique = DAG up and running, pointing towards a single access point or sink. In = this context, I think I see your concern: if the quality of these = links/paths are not monitored properly, how do we now they are good = enough? So I agree with you, we need to think about how to monitor and = evaluate the quality of these links/paths. 

This probably means slightly more state maintained = in some nodes throughout the network... Do you have any suggestion on = how to do this efficiently? I remember you were mentioning some related = work in the domain, in Anaheim. Again, the draft is not a spec yet, = and just a high level description of some needed functionalities, so any = help or suggestion on how to achieve these efficiently is = welcome.

Actually, it was neither 1 nor = 2. :)

1 is a non-starter and there are some = known techniques for preventing it, I assume the actual specification = will include them. The one caveat is that we want to minimize state = requirements and avoid things like sequence number loops (where A > B = > C > A for wraparound reasons).

I agree = with your comment on 2 -- nodes in a P2P route may need to be neither = parents nor children. My concern is a little more = subtle. 

One of the dangers of on-demand = mechanisms is that routes are established quickly, but detecting good = links requires time. Node B receiving a discovery message from node A = does not imply that A <-> B can be included in a workable route. = If node B does not have a good estimate of AB, it should not forward a = discovery message after hearing it from  A. Something as simple as = saying that a node MUST NOT forward a discovery message = if

  1) the transmitter is outside = its neighbor set, or
  2) the link to/from the = transmitter has poor properties (realize this needs to be more = precise).

might be = sufficient.

This is one of those cases where = doing the simple and easy thing (just forward!) has terrible = implications. I realize that the current statement of intent calls for = forwarded discovery messages to include metrics/cost/Rank/etc. What's = critical is that receiving a discovery packet be insufficient for = determining this value, because in LLNs it = is.

Does that make = sense?

Phil
= --Apple-Mail-77--547356553-- From prvs=747a96be7=mukul@uwm.edu Mon May 17 22:46:55 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 885BD3A6BFC for ; Mon, 17 May 2010 22:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.027 X-Spam-Level: X-Spam-Status: No, score=-0.027 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 zAoVE3D3UF48 for ; Mon, 17 May 2010 22:46:53 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 5A3E83A6BF9 for ; Mon, 17 May 2010 22:46:32 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 18 May 2010 00:46:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 1BA0A2C3800F; Tue, 18 May 2010 00:46:22 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhPYSV0knBTG; Tue, 18 May 2010 00:46:21 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id D8C262C3800E; Tue, 18 May 2010 00:46:21 -0500 (CDT) Date: Tue, 18 May 2010 00:46:20 -0500 (CDT) From: Mukul Goyal To: Anders Brandt Message-ID: <1749438870.12173221274161580557.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <441565634.12172811274161262532.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 05:46:55 -0000 Hi JP Just adding my thoughts: 1)=C2=A0 o The constraint to route only along a DAG leading to significantl= y suboptimal P2P routes and traffic congestion near the DAG root.=20 JP> You may want to soften the statement here since the path computed along= the DAG=C2=A0=20 may be sub-optimal .. it all depends on the destination, degree of meshing = of the DAG, etc ...=20 I think that the argument of not having to maintain route maintenance for s= ome nodes is=C2=A0=20 more compelling. =C2=A0=20 [Anders]=C2=A0=20 What about:=20 "The constraint to route only along a DAG potentially leading to significan= tly=20 suboptimal P2P routes and traffic congestion near the DAG root."=C2=A0=C2= =A0 ?=20 [Mukul] I will modify the text to include the factors JP mentioned. 2)=C2=A0 Such applications require a mechanism for "reactive route discover= y" and the ability to route "across DAGs".=20 JP> Why is it required to route across DAGs ? I guess that you meant "non D= AG" routes ? =C2=A0=20 2)=C2=A0 Such applications require a mechanism for "reactive route discover= y" and the ability to route "across DAGs".=20 JP> Why is it required to route across DAGs ? I guess that you meant "non D= AG" routes ? =C2=A0=20 [Anders]=C2=A0=20 Agreed. What the text should say is:=20 "across a DAG", "across the branches of a dag" or "along non-DAG routes"=C2= =A0 (pick one) =C2=A0=20 [Mukul] I prefer "non-DAG" routes. Much better than "across-DAG". 3)=C2=A0 The mechanisms described in this document are intended to be emplo= yed as complementary to RPL in specific scenarios that need point-to- point (P2P) routes between arbitrary nodes.=20 JP> More specifically, I think that we agree that it will be part of RPL, a= s an optional mechanism. =C2=A0=20 [Anders]=C2=A0=20 Negative.=20 RPL will never be able to deliver the required performance for home and=20 building without decent support for battery operation and reactive self-hea= ling.=20 [Mukul] JP, my thinking is that RPL should not characterize the P2P support as opti= onal. It should be a "must". RPL is being designed to meet requirements of = 4 application domains and atleast 2 of these domains have P2P as a critical= requirement.=20 4) Section 4.2: objective function=20 JP> You actually do not need an OF for that. Just use the metrics specified= in the Routing-metrics ID,=20 adding a path-cost-bound object (for the "good enough" criteria). =C2=A0=20 =C2=A0=20 [Anders] Great. This is an example of why it will be valuable for RPL as a whole if = the WG starts discussing=20 how to achieve the stated goals of the draft.=20 OF or metrics - I leave it for the experts to decide which is the right thi= ng. As long as I can ask for a=20 "good enough" route as result of a reactive discovery. I need the lamp to t= urn on with low delay.=20 Later, I may have time for fine-tuning the route. =C2=A0 =C2=A0=20 [Mukul] We will create a separate ID for the "measurement request/reply" part. It w= ould use the functionality provided by the Routing-metrics ID. =20 5)=C2=A0 4.6. Transport of Routing Metrics The Metric Container option defi= ned in RPL-07 can be used to carry both the aggregated end-to-end and the local values for the routing metrics being used to define the routing cost. Additional metric objects may need to be defined to carry the aggregated end-to-end routing cost and a source-route unmodified from one node to another;=20 JP> with regards to the second part of the paragraph I would suggest to use= the same metrics as defined=20 in the routing-metric ID.=20 [Mukul] I need to go back to the routing metrics ID to see what functionality it al= ready provides and what additions do we need. 6) We just need to have a section somewhere indicating that such reactive m= echanism has a cost too and the resulting=20 path cost decrease is not known a priori and may end up being close to the = DAG cost for that destination. I am not=20 questioning the usefulness of the mechanism, just make sure to indicate it.= =20 [Mukul] I will make sure that such text is added to the draft. Thanks Mukul From pthubert@cisco.com Mon May 17 23:37:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7973A6BFE for ; Mon, 17 May 2010 23:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.605 X-Spam-Level: X-Spam-Status: No, score=-3.605 tagged_above=-999 required=5 tests=[AWL=-3.606, 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 thdS2L-gfNpD for ; Mon, 17 May 2010 23:37: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 411D23A6C2E for ; Mon, 17 May 2010 23:36:27 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,253,1272844800"; d="scan'208";a="7518882" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 18 May 2010 05:57:53 +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 o4I6aIfR008423; Tue, 18 May 2010 06:36:18 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); Tue, 18 May 2010 08:36:18 +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: Tue, 18 May 2010 08:36:12 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01E85DBE@XMB-AMS-107.cisco.com> In-Reply-To: <7ED5239F-691E-448D-A174-D6B51128584D@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Source Routing Header Format Thread-Index: Acr1vzKL+77aa0CVSayUfL+M/7aMGwAlAVNA References: <6AAA6AEF-11B3-4342-BEA3-6D6D39E8154C@cs.jhu.edu> <7ED5239F-691E-448D-A174-D6B51128584D@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "JeongGil Ko (John)" X-OriginalArrivalTime: 18 May 2010 06:36:18.0554 (UTC) FILETIME=[6C2525A0:01CAF654] Cc: ROLL WG Subject: Re: [Roll] Source Routing Header Format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 06:37:02 -0000 Hi JP: For the P2P, it appears that we'll need the record route piece as well. But the record route does not preexist in IPv6 standards. It is present in my early work on tree discovery, so in a somewhat similar context of mobile routers forming networks:=20 http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header One option to move forward could be to start from that draft and make it a separate spec. We'd cleanup the mobility/tunnel pieces and make it fully agnostic to routing protocols. What does the group think? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP > Vasseur > Sent: Monday, May 17, 2010 2:44 PM > To: JeongGil Ko (John) > Cc: ROLL WG > Subject: Re: [Roll] Source Routing Header Format >=20 > Hi, >=20 > On May 7, 2010, at 8:24 AM, JeongGil Ko (John) wrote: >=20 > > Hi all, > > > > Have we decided on what the routing header format will be for point- > > to-point routing? > > The last discussion that I remember concluded with "Let's do something > > like RH0 and do tag/labels for addressing". >=20 > Right, Jonathan agreed to take the ownership of the ticket: indeed the > conclusion was RH0-like, staying within RPL domain to avoid security issues. > Labels may come next (separate ID). >=20 > Thanks. >=20 > JP. >=20 > > Do we have anything else after that? > > > > -John > > > > ------ > > JeongGil Ko (John) > > Ph.D. Student > > Department of Computer Science > > Johns Hopkins University > > http://www.cs.jhu.edu/~jgko > > > > _______________________________________________ > > 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 From prvs=747a96be7=mukul@uwm.edu Mon May 17 23:46:27 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2253A6942 for ; Mon, 17 May 2010 23:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.025 X-Spam-Level: X-Spam-Status: No, score=-0.025 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 gzPBMv0G1Mnd for ; Mon, 17 May 2010 23:46:26 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id E8A003A6BFE for ; Mon, 17 May 2010 23:46:24 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 18 May 2010 01:46:16 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id E3B742C38011; Tue, 18 May 2010 01:46:16 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAP6zawkRq-Y; Tue, 18 May 2010 01:46:16 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id BA2352C3800D; Tue, 18 May 2010 01:46:16 -0500 (CDT) Date: Tue, 18 May 2010 01:46:16 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <463402115.12177031274165176659.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2099818134.12176841274164916968.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 06:46:27 -0000 Philip [Philip] I agree with your comment on 2 -- nodes in a P2P route may need to be neith= er parents nor children. My concern is a little more subtle.=C2=A0=20 One of the dangers of on-demand mechanisms is that routes are established q= uickly, but detecting good links requires time. Node B receiving a discover= y message from node A does not imply that A <-> B can be included in a work= able route. If node B does not have a good estimate of AB, it should not fo= rward a discovery message after hearing it from =C2=A0A. Something as simpl= e as saying that a node MUST NOT forward a discovery message if=20 =C2=A0=C2=A01) the transmitter is outside its neighbor set, or=20 =C2=A0=C2=A02) the link to/from the transmitter has poor properties (realiz= e this needs to be more precise).=20 might be sufficient.=20 This is one of those cases where doing the simple and easy thing (just forw= ard!) has terrible implications. I realize that the current statement of in= tent calls for forwarded discovery messages to include metrics/cost/Rank/et= c. What's critical is that receiving a discovery packet be insufficient for= determining this value, because in LLNs it is.=20 Does that make sense?=20 [Mukul] I agree that a node should forward a Discovery message only if it has a goo= d estimate of the "link cost in the right direction". I guess this can be m= ade explicit in the draft. But, the routing metric may simply be hop-count,= in which case the receipt of the Discovery message is a reasonable proof o= f the existence of the "hop". So, I won't say that receiving a discovery pa= cket is always insufficient to determine the "link cost" value. It really d= epends on the definition of the routing cost. Thanks Mukul From Daniel.Popa@itron.com Mon May 17 23:59:19 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CDAF3A6C2C for ; Mon, 17 May 2010 23:59:19 -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 ug5nTs4EMPiK for ; Mon, 17 May 2010 23:59:17 -0700 (PDT) Received: from itron.com (itron9-144.itron.com [198.182.9.144]) by core3.amsl.com (Postfix) with ESMTP id AABB13A6C28 for ; Mon, 17 May 2010 23:59:17 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.112]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Mon, 17 May 2010 23:59:09 -0700 From: "Popa, Daniel" To: "Pascal Thubert (pthubert)" , JP Vasseur , "JeongGil Ko (John)" Date: Mon, 17 May 2010 23:59:06 -0700 Thread-Topic: [Roll] Source Routing Header Format Thread-Index: Acr1vzKL+77aa0CVSayUfL+M/7aMGwAlAVNAAAD4qXA= Message-ID: <83027ECE5ECDC04E9BA5350B756A88E158D096CBE1@ITR-EXMBXVS-1.itron.com> References: <6AAA6AEF-11B3-4342-BEA3-6D6D39E8154C@cs.jhu.edu> <7ED5239F-691E-448D-A174-D6B51128584D@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01E85DBE@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01E85DBE@XMB-AMS-107.cisco.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: ROLL WG Subject: Re: [Roll] Source Routing Header Format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 06:59:19 -0000 Pascal,=20 +1. It seems a good starting point.=20 Daniel > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Pascal Thubert (pthubert) > Sent: Tuesday, May 18, 2010 8:36 AM > To: JP Vasseur; JeongGil Ko (John) > Cc: ROLL WG > Subject: Re: [Roll] Source Routing Header Format >=20 > Hi JP: >=20 > For the P2P, it appears that we'll need the record route piece as well. > But the record route does not preexist in IPv6 standards. >=20 > It is present in my early work on tree discovery, so in a somewhat > similar context of mobile routers forming networks: > http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header >=20 > One option to move forward could be to start from that draft and make > it > a separate spec. >=20 > We'd cleanup the mobility/tunnel pieces and make it fully agnostic to > routing protocols. >=20 > What does the group think? >=20 > Pascal >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP > > Vasseur > > Sent: Monday, May 17, 2010 2:44 PM > > To: JeongGil Ko (John) > > Cc: ROLL WG > > Subject: Re: [Roll] Source Routing Header Format > > > > Hi, > > > > On May 7, 2010, at 8:24 AM, JeongGil Ko (John) wrote: > > > > > Hi all, > > > > > > Have we decided on what the routing header format will be for > point- > > > to-point routing? > > > The last discussion that I remember concluded with "Let's do > something > > > like RH0 and do tag/labels for addressing". > > > > Right, Jonathan agreed to take the ownership of the ticket: indeed > the > > conclusion was RH0-like, staying within RPL domain to avoid security > issues. > > Labels may come next (separate ID). > > > > Thanks. > > > > JP. > > > > > Do we have anything else after that? > > > > > > -John > > > > > > ------ > > > JeongGil Ko (John) > > > Ph.D. Student > > > Department of Computer Science > > > Johns Hopkins University > > > http://www.cs.jhu.edu/~jgko > > > > > > _______________________________________________ > > > 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 jpv@cisco.com Tue May 18 00:12:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240FF3A67B6 for ; Tue, 18 May 2010 00:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.845 X-Spam-Level: X-Spam-Status: No, score=-7.845 tagged_above=-999 required=5 tests=[AWL=0.154, 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 A4kNGKKGQOrR for ; Tue, 18 May 2010 00:12:11 -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 371923A67A4 for ; Tue, 18 May 2010 00:12: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: AvsEAJ7a8UurR7H+/2dsb2JhbACddnGiApl5hRAEjzw X-IronPort-AV: E=Sophos;i="4.53,253,1272844800"; d="scan'208";a="198819680" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 18 May 2010 07:11:59 +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 o4I7Brki015367; Tue, 18 May 2010 07:11:59 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 09:11:58 +0200 Received: from ams-jvasseur-8716.cisco.com ([10.55.201.135]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 09:11:57 +0200 Message-Id: <1507833C-E1C6-47FE-BCC6-804E9F9915FC@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <1749438870.12173221274161580557.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 May 2010 09:11:57 +0200 References: <1749438870.12173221274161580557.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 May 2010 07:11:58.0354 (UTC) FILETIME=[6790B720:01CAF659] Cc: roll Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 07:12:13 -0000 Hi Mukul, On May 18, 2010, at 7:46 AM, Mukul Goyal wrote: > Hi JP > > Just adding my thoughts: > > 1) o The constraint to route only along a DAG leading to > significantly suboptimal P2P routes and traffic congestion near the > DAG root. > JP> You may want to soften the statement here since the path > computed along the DAG > may be sub-optimal .. it all depends on the destination, degree of > meshing of the DAG, etc ... > I think that the argument of not having to maintain route > maintenance for some nodes is > more compelling. > > [Anders] > What about: > "The constraint to route only along a DAG potentially leading to > significantly > suboptimal P2P routes and traffic congestion near the DAG root." ? > > [Mukul] > I will modify the text to include the factors JP mentioned. > OK > 2) Such applications require a mechanism for "reactive route > discovery" and the ability to route "across DAGs". > > JP> Why is it required to route across DAGs ? I guess that you meant > "non DAG" routes ? > 2) Such applications require a mechanism for "reactive route > discovery" and the ability to route "across DAGs". > > > JP> Why is it required to route across DAGs ? I guess that you meant > "non DAG" routes ? > > [Anders] > Agreed. What the text should say is: > "across a DAG", "across the branches of a dag" or "along non-DAG > routes" (pick one) > > [Mukul] > I prefer "non-DAG" routes. Much better than "across-DAG". > OK > 3) The mechanisms described in this document are intended to be > employed as complementary to RPL in specific scenarios that need > point-to- > point (P2P) routes between arbitrary nodes. > > > JP> More specifically, I think that we agree that it will be part of > RPL, as an optional mechanism. > > [Anders] > Negative. > > RPL will never be able to deliver the required performance for home > and > building without decent support for battery operation and reactive > self-healing. > > [Mukul] > JP, my thinking is that RPL should not characterize the P2P support > as optional. It should be a "must". RPL is being designed to meet > requirements of 4 application domains and atleast 2 of these domains > have P2P as a critical requirement. > Let clarify again. ROLL will deliver a solution. This is not optional in the sense that we may do it or not do it. As you pointed out, this is a MUST requirements so we have to have a solution, and we're on the right track. That being said, that feature may not be required in all RPL implementations since there are a number of use case where this may not be required. As in many other protocols, not all features are required. That's all. > 4) Section 4.2: objective function > > > JP> You actually do not need an OF for that. Just use the metrics > specified in the Routing-metrics ID, > adding a path-cost-bound object (for the "good enough" criteria). > > [Anders] > Great. This is an example of why it will be valuable for RPL as a > whole if the WG starts discussing > how to achieve the stated goals of the draft. > OF or metrics - I leave it for the experts to decide which is the > right thing. As long as I can ask for a > "good enough" route as result of a reactive discovery. I need the > lamp to turn on with low delay. > Later, I may have time for fine-tuning the route. > > [Mukul] > We will create a separate ID for the "measurement request/reply" > part. It would use the functionality provided by the Routing-metrics > ID. > Excellent, thanks. > > 5) 4.6. Transport of Routing Metrics The Metric Container option > defined in RPL-07 can be used to carry > both the aggregated end-to-end and the local values for the routing > metrics being used to define the routing cost. Additional metric > objects may need to be defined to carry the aggregated end-to-end > routing cost and a source-route unmodified from one node to another; > > > JP> with regards to the second part of the paragraph I would suggest > to use the same metrics as defined > in the routing-metric ID. > > [Mukul] > I need to go back to the routing metrics ID to see what > functionality it already provides and what additions do we need. > OK let me know if you have any question. > 6) We just need to have a section somewhere indicating that such > reactive mechanism has a cost too and the resulting > path cost decrease is not known a priori and may end up being close > to the DAG cost for that destination. I am not > questioning the usefulness of the mechanism, just make sure to > indicate it. > > [Mukul] > I will make sure that such text is added to the draft. > Thanks. JP. > Thanks > Mukul > From abr@sdesigns.dk Tue May 18 00:32:26 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9BF3A67D7 for ; Tue, 18 May 2010 00:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-0.573, 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 e-JCoyjDv5wD for ; Tue, 18 May 2010 00:32: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 673D53A67A6 for ; Tue, 18 May 2010 00:32:24 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 May 2010 09:32:15 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A165@zensys17.zensys.local> In-Reply-To: <463402115.12177031274165176659.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 Thread-Index: Acr2VdYFgwkZy5psSCuTVOb74mx7oQABbYnA References: <2099818134.12176841274164916968.JavaMail.root@mail02.pantherlink.uwm.edu> <463402115.12177031274165176659.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Anders Brandt" To: "Mukul Goyal" , "Philip Levis" Cc: roll , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 07:32:26 -0000 [Anders] comment inline ... Cheers, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Mukul Goyal > Sent: Tuesday, May 18, 2010 08:46 > To: Philip Levis > Cc: roll; Emmanuel Baccelli > Subject: Re: [Roll] Fwd: New Version Notification=20 > fordraft-dt-roll-p2p-rpl-00 >=20 > Philip >=20 > [Philip] > I agree with your comment on 2 -- nodes in a P2P route may=20 > need to be neither parents nor children. My concern is a=20 > little more subtle.=A0=20 >=20 > One of the dangers of on-demand mechanisms is that routes are=20 > established quickly, but detecting good links requires time.=20 > Node B receiving a discovery message from node A does not=20 > imply that A <-> B can be included in a workable route. If=20 > node B does not have a good estimate of AB, it should not=20 > forward a discovery message after hearing it from =A0A.=20 > Something as simple as saying that a node MUST NOT forward a=20 > discovery message if=20 >=20 >=20 > =A0=A01) the transmitter is outside its neighbor set, or > =A0=A02) the link to/from the transmitter has poor properties=20 > (realize this needs to be more precise).=20 >=20 >=20 > might be sufficient.=20 >=20 > This is one of those cases where doing the simple and easy=20 > thing (just forward!) has terrible implications. I realize=20 > that the current statement of intent calls for forwarded=20 > discovery messages to include metrics/cost/Rank/etc. What's=20 > critical is that receiving a discovery packet be insufficient=20 > for determining this value, because in LLNs it is.=20 >=20 >=20 > Does that make sense?=20 >=20 > [Mukul] > I agree that a node should forward a Discovery message only=20 > if it has a good estimate of the "link cost in the right=20 > direction". I guess this can be made explicit in the draft.=20 > But, the routing metric may simply be hop-count, in which=20 > case the receipt of the Discovery message is a reasonable=20 > proof of the existence of the "hop". So, I won't say that=20 > receiving a discovery packet is always insufficient to=20 > determine the "link cost" value. It really depends on the=20 > definition of the routing cost. [Anders] I understand your concern and if you have resources in a node for doing more intelligent forwarding decisions, this is wonderful. For the most constrained nodes, however, I love the simplicity of Trickle where you forward (randomized schedule) as long as you have picked up less than n copies of the discovery message from you direct range neighbors. We must ensure that the most constrained nodes can do something like this. For sure, such nodes cannot hold link properties for all neighbors in a dense network. >=20 > Thanks > Mukul >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From jpv@cisco.com Tue May 18 02:27:45 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13203A6C7E for ; Tue, 18 May 2010 02:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.22 X-Spam-Level: X-Spam-Status: No, score=-8.22 tagged_above=-999 required=5 tests=[AWL=0.520, 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 hiae3ZQA6H38 for ; Tue, 18 May 2010 02:27: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 9E16A3A6C7F for ; Tue, 18 May 2010 02:24:41 -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: AvsEAAb68UurR7H+/2dsb2JhbACde3GiU5l9hRAEjzw X-IronPort-AV: E=Sophos;i="4.53,254,1272844800"; d="scan'208";a="531402788" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 18 May 2010 09:24:34 +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 o4I9O8MV023819; Tue, 18 May 2010 09:24:33 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 11:24:31 +0200 Received: from ams-jvasseur-8716.cisco.com ([10.55.201.135]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 11:24:30 +0200 Message-Id: <2E80D99C-9328-439C-B981-2E29A904E913@cisco.com> From: JP Vasseur To: Mukul Goyal , Anders Brandt In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A165@zensys17.zensys.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 May 2010 11:24:29 +0200 References: <2099818134.12176841274164916968.JavaMail.root@mail02.pantherlink.uwm.edu> <463402115.12177031274165176659.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E0142A165@zensys17.zensys.local> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 May 2010 09:24:31.0252 (UTC) FILETIME=[EBDCA540:01CAF66B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17390.006 X-TM-AS-Result: No--29.031300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: Emmanuel Baccelli , roll WG Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 09:27:45 -0000 Hi Anders, Comments (still technical, co-chair hat off again) On May 18, 2010, at 9:32 AM, Anders Brandt wrote: > [Anders] comment inline ... > > Cheers, > Anders > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of Mukul Goyal >> Sent: Tuesday, May 18, 2010 08:46 >> To: Philip Levis >> Cc: roll; Emmanuel Baccelli >> Subject: Re: [Roll] Fwd: New Version Notification >> fordraft-dt-roll-p2p-rpl-00 >> >> Philip >> >> [Philip] >> I agree with your comment on 2 -- nodes in a P2P route may >> need to be neither parents nor children. My concern is a >> little more subtle. >> >> One of the dangers of on-demand mechanisms is that routes are >> established quickly, but detecting good links requires time. >> Node B receiving a discovery message from node A does not >> imply that A <-> B can be included in a workable route. If >> node B does not have a good estimate of AB, it should not >> forward a discovery message after hearing it from A. >> Something as simple as saying that a node MUST NOT forward a >> discovery message if >> >> >> 1) the transmitter is outside its neighbor set, or >> 2) the link to/from the transmitter has poor properties >> (realize this needs to be more precise). >> >> >> might be sufficient. >> >> This is one of those cases where doing the simple and easy >> thing (just forward!) has terrible implications. I realize >> that the current statement of intent calls for forwarded >> discovery messages to include metrics/cost/Rank/etc. What's >> critical is that receiving a discovery packet be insufficient >> for determining this value, because in LLNs it is. >> >> >> Does that make sense? >> >> [Mukul] >> I agree that a node should forward a Discovery message only >> if it has a good estimate of the "link cost in the right >> direction". I guess this can be made explicit in the draft. >> But, the routing metric may simply be hop-count, in which >> case the receipt of the Discovery message is a reasonable >> proof of the existence of the "hop". So, I won't say that >> receiving a discovery packet is always insufficient to >> determine the "link cost" value. It really depends on the >> definition of the routing cost. > Still the issue is that you may not know that cost, especially if the A-B link does not belong to the DAG. The wording proposed by Phil makes sense to me. > [Anders] I understand your concern and if you have resources > in a node for doing more intelligent forwarding decisions, this > is wonderful. > For the most constrained nodes, however, I love the simplicity > of Trickle where you forward (randomized schedule) as long as > you have picked up less than n copies of the discovery message > from you direct range neighbors. But that requires to be cautious too since that could eliminate some "good" paths too, and in particular the ones that are better than the DODAG path. > We must ensure that the most constrained nodes can do something > like this. For sure, such nodes cannot hold link properties for > all neighbors in a dense network. > > >> >> Thanks >> Mukul >> >> _______________________________________________ >> 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 jpv@cisco.com Tue May 18 02:45:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9EF3A6862 for ; Tue, 18 May 2010 02:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.164 X-Spam-Level: X-Spam-Status: No, score=-9.164 tagged_above=-999 required=5 tests=[AWL=1.435, 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 DZKrvYTTbGJU for ; Tue, 18 May 2010 02:45:33 -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 D89013A6843 for ; Tue, 18 May 2010 02:45:32 -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: AjYCAHv+8UuQ/uCWe2dsb2JhbACdexUBARYiBhyiaJoBgmeCKQQ X-IronPort-AV: E=Sophos;i="4.53,254,1272844800"; d="scan'208";a="61492047" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 May 2010 09:45: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 o4I9jOKe004247 for ; Tue, 18 May 2010 09:45:24 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 11:45:23 +0200 Received: from ams-jvasseur-8716.cisco.com ([10.55.201.135]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 11:45:23 +0200 Message-Id: <4EFB7C64-AC29-4B5E-B71E-1B842AF60379@cisco.com> From: JP Vasseur To: roll WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 May 2010 11:45:23 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 May 2010 09:45:23.0597 (UTC) FILETIME=[D65153D0:01CAF66E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17390.006 X-TM-AS-Result: No--3.744100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Examples moved in a separate document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 09:45:34 -0000 Dear all, Since the very first revisions of the RPL ID, we added examples to help understand the mechanisms. That said, at some point, these examples have to be removed from the specification. We have two options: 1) Just remove these examples 2) Remove them from the core specification to a separate informational document. Note that some of them are now obsolete and would require some time to be updated in light of the recent mechanisms added to the specifications. Nothing urgent, but should you be interested by this work, let us know. Thanks. JP. From jpv@cisco.com Tue May 18 02:48:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA283A6862 for ; Tue, 18 May 2010 02:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.901 X-Spam-Level: X-Spam-Status: No, score=-7.901 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_50=0.001, 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 NMpkOjX8Tl8i for ; Tue, 18 May 2010 02:48:13 -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 B25D23A68B8 for ; Tue, 18 May 2010 02:48:06 -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: AvsEAPL+8UurR7Ht/2dsb2JhbACde3Gib5oBhRAE X-IronPort-AV: E=Sophos;i="4.53,254,1272844800"; d="scan'208,217";a="198892070" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 18 May 2010 09:47:57 +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 o4I9lqTg007816 for ; Tue, 18 May 2010 09:47:57 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 11:47:42 +0200 Received: from ams-jvasseur-8716.cisco.com ([10.55.201.135]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 11:47:42 +0200 Message-Id: From: JP Vasseur To: roll WG Content-Type: multipart/alternative; boundary=Apple-Mail-48--483881684 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 May 2010 11:47:41 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 May 2010 09:47:42.0502 (UTC) FILETIME=[291C8C60:01CAF66F] Subject: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 09:48:14 -0000 --Apple-Mail-48--483881684 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear WG, Here is a quick status. First, we would like to thank the WG again for the continuous effort and lots of fruitful and productive work ! As discussed in Anaheim, the plan is still to Last Call RPL before the next IETF. The plan is to release the next revision of the RPL I-D by end of next week. Rev-08 will address the following: 1) Security section (integrating the work on the security DT) 2) New DAO mechanism (cleaner and more simple), as agreed on the Mailing List 3) Basic source routing => See also companion drafts to be published very soon for (RH-0 like) 4) Updated manageability section 5) DAO ACK 6) Trickle algorithm removed from the core specification (in a separate doc), Examples removed 7) Several Edits, clarifications, ... I had a discussion with David, and the plan is to have the P2P a separate ID (the current RPL specification provides basic P2P, with "advanced" P2P defined in that I-D), with the objective to progress both documents in parallel. What else ? We need to progress a few other documents: 1) Use of the RPL TLV: see draft-hui-6man-rpl-option (6man WG) 2) Source routing header (RH-0 like): to be published soon (Jonathan/ David) 3) RPL Variables (ticket #22) 4) ID related to measurement from P2P (if consensus on Mailing list) Looking forward to your comments as soon as rev-08 will be published. Thanks. JP and David. --Apple-Mail-48--483881684 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = WG,

Here is a quick status. First, we would like to = thank the WG again for the continuous effort and lots of fruitful and = productive work ! As discussed in Anaheim, the plan is still to Last = Call RPL before the next IETF. The plan is to release the next revision = of the RPL I-D by end of next week. Rev-08 will  address the = following:

1) Security section = (integrating the work on the security DT)
2) New DAO mechanism = (cleaner and more simple), as agreed on the Mailing = List
3) Basic source routing  =3D> See also companion = drafts to be published very soon for (RH-0 like)
4) Updated = manageability section
5) DAO ACK
6) Trickle = algorithm removed from the core specification (in a separate doc), = Examples removed
7) Several Edits, clarifications, = ... 

I had a discussion with David, and = the plan is to have the P2P a separate ID (the current RPL specification = provides basic P2P, with "advanced" P2P defined in that I-D), with the = objective to progress both documents in = parallel. 

What else = ?
We need to progress a few other = documents:
1) Use of the RPL TLV: = see draft-hui-6man-rpl-option (6man WG)
2) Source routing = header (RH-0 like): to be published soon (Jonathan/David)
3) = RPL Variables (ticket #22)
4) ID related to measurement from = P2P (if consensus on Mailing list)

Looking = forward to your comments as soon as rev-08 will be = published.

Thanks.

JP = and David.
= --Apple-Mail-48--483881684-- From abr@sdesigns.dk Tue May 18 03:12:01 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E013A6782 for ; Tue, 18 May 2010 03:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-0.547, 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 0EJgLz0Twrt2 for ; Tue, 18 May 2010 03:12:00 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id F30823A6914 for ; Tue, 18 May 2010 03:11:58 -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_01CAF672.886ECD1E" Date: Tue, 18 May 2010 12:11:50 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A168@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Status Thread-Index: Acr2bzqPWxPN57CbQt+h7yszz74kKgAAyU0A References: From: "Anders Brandt" To: "JP Vasseur" , "roll WG" Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 10:12:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF672.886ECD1E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi JP ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Tuesday, May 18, 2010 11:48 To: roll WG Subject: [Roll] RPL Status =09 =09 Dear WG,=20 Here is a quick status. First, we would like to thank the WG again for the continuous effort and lots of fruitful and productive work ! As discussed in Anaheim, the plan is still to Last Call RPL before the next IETF. The plan is to release the next revision of the RPL I-D by end of next week. Rev-08 will address the following: 1) Security section (integrating the work on the security DT) 2) New DAO mechanism (cleaner and more simple), as agreed on the Mailing List 3) Basic source routing =3D> See also companion drafts to be published very soon for (RH-0 like) 4) Updated manageability section 5) DAO ACK 6) Trickle algorithm removed from the core specification (in a separate doc), Examples removed 7) Several Edits, clarifications, ...=20 I had a discussion with David, and the plan is to have the P2P a separate ID (the current RPL specification provides basic P2P, with "advanced" P2P defined in that I-D), with the objective to progress both documents in parallel. =20 =20 May I suggest: (the current RPL specification provides rudimentary P2P, with the required and sufficient P2P defined in that I-D)=20 =20 ;-) What else ? We need to progress a few other documents: 1) Use of the RPL TLV: see draft-hui-6man-rpl-option (6man WG) 2) Source routing header (RH-0 like): to be published soon (Jonathan/David) 3) RPL Variables (ticket #22) 4) ID related to measurement from P2P (if consensus on Mailing list) Looking forward to your comments as soon as rev-08 will be published. Thanks. JP and David. ------_=_NextPart_001_01CAF672.886ECD1E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
hi JP

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent:=20 Tuesday, May 18, 2010 11:48
To: roll WG
Subject: = [Roll]=20 RPL Status

Dear WG,

Here is a quick status. First, we would like to thank the WG = again for=20 the continuous effort and lots of fruitful and productive work ! As = discussed=20 in Anaheim, the plan is still to Last Call RPL before the next IETF. = The plan=20 is to release the next revision of the RPL I-D by end of next week. = Rev-08=20 will  address the following:

1) Security section (integrating the work on the security = DT)
2) New DAO mechanism (cleaner and more simple), as agreed on=20 the Mailing List
3) Basic source routing  =3D> See also companion drafts = to be=20 published very soon for (RH-0 like)
4) Updated manageability section
5) DAO ACK
6) Trickle algorithm removed from the core specification (in a = separate=20 doc), Examples removed
7) Several Edits, clarifications, ... 

I had a discussion with David, and the plan is to have the P2P a = separate=20 ID (the current RPL specification provides basic P2P, with "advanced" = P2P=20 defined in that I-D), with the objective to progress both documents in = parallel.  
 
May I suggest:
(the current RPL = specification=20 provides rudimentary P2P, with the required and sufficient P2P = defined in=20 that I-D) 
 
;-)

What else ?
We need to progress a few other documents:
1) Use of the RPL TLV: see draft-hui-6man-rpl-option (6man = WG)
2) Source routing header (RH-0 like): to be published soon=20 (Jonathan/David)
3) RPL Variables (ticket #22)
4) ID related to measurement from P2P (if consensus on Mailing=20 list)

Looking forward to your comments as soon as rev-08 will be=20 published.

Thanks.

JP and David.
------_=_NextPart_001_01CAF672.886ECD1E-- From trac@tools.ietf.org Tue May 18 04:09:42 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B213A687B for ; Tue, 18 May 2010 04:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.366 X-Spam-Level: X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=0.234, 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 69OqoShRLf7b for ; Tue, 18 May 2010 04:09:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 38E7F3A6911 for ; Tue, 18 May 2010 04:09:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OEKg1-0007Ek-Qu; Tue, 18 May 2010 04:09:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Tue, 18 May 2010 11:09:33 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/27#comment:1 Message-ID: <064.a45961d29bfbf464caf869d88f2d33f4@tools.ietf.org> References: <055.c6bd3c511a71be1395c9120dcf8adad6@tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <055.c6bd3c511a71be1395c9120dcf8adad6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@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: roll@ietf.org Subject: Re: [Roll] [roll] #27: DAO ACK ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 11:09:42 -0000 #27: DAO ACK ? --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: task | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: From: "Pascal Thubert (pthubert)" Date: May 13, 2010 6:49:22 PM CEDT To: Subject: Re: [Roll] closing on #27: DAO ACK ? Thanks you all This poll only got positive answers. I asked the authors and got no negative either. Let's include a DAO Ack in 08 then. Hopefully that's very soon. Pascal -- Ticket URL: roll From daniel.gavelle@jennic.com Tue May 18 05:54:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA07A3A6B62 for ; Tue, 18 May 2010 05:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 n+B3zaLBdxzp for ; Tue, 18 May 2010 05:54:36 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 1FCB63A6A81 for ; Tue, 18 May 2010 05:54:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id B7C259BE503 for ; Tue, 18 May 2010 13:54:26 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC9Oqimp0Stg for ; Tue, 18 May 2010 13:54:26 +0100 (BST) Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id A137D9BE4FF for ; Tue, 18 May 2010 13:54:26 +0100 (BST) Message-ID: <4BF28E02.4080000@jennic.com> Date: Tue, 18 May 2010 13:54:26 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ROLL WG 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> In-Reply-To: <83027ECE5ECDC04E9BA5350B756A88E158D096CBE1@ITR-EXMBXVS-1.itron.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Source Routing Header Format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 12:54:37 -0000 All, Whichever source routing header we use, it will be good if we don't need to carry the full IPv6 address of each hop. This is especially important when using 6LowPAN. If we don't compress the addresses, it won't take many hops before the routing header overflows the first 6LowPAN fragment. Daniel. Popa, Daniel wrote: > Pascal, > > +1. It seems a good starting point. > > Daniel > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >> Pascal Thubert (pthubert) >> Sent: Tuesday, May 18, 2010 8:36 AM >> To: JP Vasseur; JeongGil Ko (John) >> Cc: ROLL WG >> Subject: Re: [Roll] Source Routing Header Format >> >> Hi JP: >> >> For the P2P, it appears that we'll need the record route piece as well. >> But the record route does not preexist in IPv6 standards. >> >> It is present in my early work on tree discovery, so in a somewhat >> similar context of mobile routers forming networks: >> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header >> >> One option to move forward could be to start from that draft and make >> it >> a separate spec. >> >> We'd cleanup the mobility/tunnel pieces and make it fully agnostic to >> routing protocols. >> >> What does the group think? >> >> Pascal >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> Of JP >>> Vasseur >>> Sent: Monday, May 17, 2010 2:44 PM >>> To: JeongGil Ko (John) >>> Cc: ROLL WG >>> Subject: Re: [Roll] Source Routing Header Format >>> >>> Hi, >>> >>> On May 7, 2010, at 8:24 AM, JeongGil Ko (John) wrote: >>> >>>> Hi all, >>>> >>>> Have we decided on what the routing header format will be for >> point- >>>> to-point routing? >>>> The last discussion that I remember concluded with "Let's do >> something >>>> like RH0 and do tag/labels for addressing". >>> Right, Jonathan agreed to take the ownership of the ticket: indeed >> the >>> conclusion was RH0-like, staying within RPL domain to avoid security >> issues. >>> Labels may come next (separate ID). >>> >>> Thanks. >>> >>> JP. >>> >>>> Do we have anything else after that? >>>> >>>> -John >>>> >>>> ------ >>>> JeongGil Ko (John) >>>> Ph.D. Student >>>> Department of Computer Science >>>> Johns Hopkins University >>>> http://www.cs.jhu.edu/~jgko >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From pierre.colle@fr.schneider-electric.com Tue May 18 07:10:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852A13A6A20 for ; Tue, 18 May 2010 07:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=-0.650, 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 tw6V8UlH40nu for ; Tue, 18 May 2010 07:10:21 -0700 (PDT) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by core3.amsl.com (Postfix) with ESMTP id B9AA63A6ABC for ; Tue, 18 May 2010 07:09:55 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX01.eud.schneider-electric.com with ESMTP id 2010051816025751-25919 ; Tue, 18 May 2010 16:02:57 +0200 From: pierre.colle@fr.schneider-electric.com To: roll@ietf.org Message-ID: Date: Tue, 18 May 2010 16:09:41 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 18/05/2010 16:09:47, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 18/05/2010 16:02:57, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 18/05/2010 16:02:59, Serialize complete at 18/05/2010 16:02:59 Content-type: multipart/alternative; Boundary="0__=4EBBFDB4DFDE4C158f9e8a93df938690918c4EBBFDB4DFDE4C15" Content-Disposition: inline Subject: [Roll] Pierre Colle/FR/Schneider est absent(e). X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 14:10:24 -0000 --0__=4EBBFDB4DFDE4C158f9e8a93df938690918c4EBBFDB4DFDE4C15 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Je serai absent(e) =E0 partir du 16/05/2010 de retour le 20/05/2010. I am currently out of office. Best regards, Pierre = --0__=4EBBFDB4DFDE4C158f9e8a93df938690918c4EBBFDB4DFDE4C15 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Je serai absent(e) =E0 partir du 16/05/2010 de retour le 20/05/201= 0.

I am currently out of office.

Best regards,

Pierre

= --0__=4EBBFDB4DFDE4C158f9e8a93df938690918c4EBBFDB4DFDE4C15-- From richard.kelsey@ember.com Tue May 18 07:50:04 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4493A6B97 for ; Tue, 18 May 2010 07:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[AWL=-0.613, 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 9mGnU+PgLdHM for ; Tue, 18 May 2010 07:50:03 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 0C9CD28C17C for ; Tue, 18 May 2010 07:47:17 -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); Tue, 18 May 2010 10:50:36 -0400 Date: Tue, 18 May 2010 10:46:42 -0400 Message-Id: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: (message from JP Vasseur on Tue, 18 May 2010 11:47:41 +0200) From: Richard Kelsey References: X-OriginalArrivalTime: 18 May 2010 14:50:36.0410 (UTC) FILETIME=[799AD5A0:01CAF699] Cc: roll@ietf.org Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 14:50:04 -0000 > From: JP Vasseur > Date: Tue, 18 May 2010 11:47:41 +0200 > > Here is a quick status. First, we would like to thank the WG again for > the continuous effort and lots of fruitful and productive work ! As > discussed in Anaheim, the plan is still to Last Call RPL before the > next IETF. We will have to do something about multicasts (ticket #30). The multicast text in the current draft has a number of limitiations; in particular, it requires that all nodes cache DAOs. Forwarding multicasts using unicasts makes sense if relatively few nodes need to receive them. For a multicast that needs to get to most or all of a network, using unicasts seems likely to be both unreliable and inefficient. -Richard Kelsey From pal@cs.stanford.edu Tue May 18 08:59:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1EC3A6828 for ; Tue, 18 May 2010 08:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.234 X-Spam-Level: X-Spam-Status: No, score=-5.234 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_20=-0.74, 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 1K8Bgh1rnwjH for ; Tue, 18 May 2010 08:59:01 -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 9B6E33A69ED for ; Tue, 18 May 2010 08:58:53 -0700 (PDT) Received: from dnab4046bc.stanford.edu ([171.64.70.188]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OEPBu-0002ET-2Y; Tue, 18 May 2010 08:58:46 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-88--462936371 From: Philip Levis In-Reply-To: <2E80D99C-9328-439C-B981-2E29A904E913@cisco.com> Date: Tue, 18 May 2010 08:36:46 -0700 Message-Id: <1420C792-ACE0-481A-86A0-D5578A165470@cs.stanford.edu> References: <2099818134.12176841274164916968.JavaMail.root@mail02.pantherlink.uwm.edu> <463402115.12177031274165176659.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E0142A165@zensys17.zensys.local> <2E80D99C-9328-439C-B981-2E29A904E913@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1078) X-Scan-Signature: f52b81a2b0b1468c47a83f31a7d93b0f Cc: roll WG , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 15:59:02 -0000 --Apple-Mail-88--462936371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 18, 2010, at 2:24 AM, JP Vasseur wrote: >=20 >=20 >> [Anders] I understand your concern and if you have resources >> in a node for doing more intelligent forwarding decisions, this >> is wonderful. >> For the most constrained nodes, however, I love the simplicity >> of Trickle where you forward (randomized schedule) as long as >> you have picked up less than n copies of the discovery message >> from you direct range neighbors. >=20 > But that requires to be cautious too since that could eliminate some = "good" paths too, and > in particular the ones that are better than the DODAG path. Anders -- are you suggesting using Trickle as the route discovery = mechanism, or as the data delivery mechanism? Phil= --Apple-Mail-88--462936371 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii



[Anders] I understand your concern and if you have = resources
in a node for doing = more intelligent forwarding decisions, this
is wonderful.
For = the most constrained nodes, however, I love the = simplicity
of Trickle where = you forward (randomized schedule) as long as
you have picked up less than n copies of the discovery = message
from you direct range = neighbors.

But that requires to be cautious too = since that could eliminate some "good" paths too, and
in particular = the ones that are better than the DODAG = path.

Anders -- are you suggesting = using Trickle as the route discovery mechanism, or as the data delivery = mechanism?

Phil
= --Apple-Mail-88--462936371-- From pal@cs.stanford.edu Tue May 18 08:59:06 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3D73A6BA1 for ; Tue, 18 May 2010 08:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.839 X-Spam-Level: X-Spam-Status: No, score=-4.839 tagged_above=-999 required=5 tests=[AWL=-0.840, 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 BUdKpXCOzJi6 for ; Tue, 18 May 2010 08:59:05 -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 EDE573A69FF for ; Tue, 18 May 2010 08:58:57 -0700 (PDT) Received: from dnab4046bc.stanford.edu ([171.64.70.188]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OEPBv-0002ET-BF; Tue, 18 May 2010 08:58:50 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <463402115.12177031274165176659.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Tue, 18 May 2010 08:39:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <463402115.12177031274165176659.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1078) X-Scan-Signature: 980022258218d8e0da9e8fd80fb6777b Cc: roll , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 15:59:06 -0000 On May 17, 2010, at 11:46 PM, Mukul Goyal wrote: > [Mukul] > I agree that a node should forward a Discovery message only if it has = a good estimate of the "link cost in the right direction". I guess this = can be made explicit in the draft. But, the routing metric may simply be = hop-count, in which case the receipt of the Discovery message is a = reasonable proof of the existence of the "hop". So, I won't say that = receiving a discovery packet is always insufficient to determine the = "link cost" value. It really depends on the definition of the routing = cost. There is extensive empirical evidence that using hopcount is a terrible = idea. If the routing metric is hop-count then the LLN will not work = well; you are better off routing up and down the DAG than dynamically = discovering routes. The protocol can't have it both ways: argue that it = quickly detects "good enough" routes with low stretch yet also needs to = support detecting terrible routes.=20 Hopcount as a metric is a myth that entered our imagination due to = terrible wireless simulations. It is a simplification that does not = work. Let's move past the 1990s and stop considering hopcount as = something that RPL needs to accommodate. Remember, we're talking about = LLNs: Lossy and Low Power Networks. Phil= From pthubert@cisco.com Tue May 18 09:18:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A44F28C164 for ; Tue, 18 May 2010 09:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.844 X-Spam-Level: X-Spam-Status: No, score=-4.844 tagged_above=-999 required=5 tests=[AWL=-2.245, 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 VQDB8S397gpm for ; Tue, 18 May 2010 09:18:22 -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 428253A6BFA for ; Tue, 18 May 2010 09:13:11 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,256,1272844800"; d="scan'208";a="7562497" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 18 May 2010 15:34:36 +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 o4IGD2nj029843; Tue, 18 May 2010 16:13:02 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); Tue, 18 May 2010 18:13:02 +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: Tue, 18 May 2010 18:12:59 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01E861A6@XMB-AMS-107.cisco.com> In-Reply-To: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Status Thread-Index: Acr2mWeTPg3oe/NKSPGptOyPXdLLVgAC17wA References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" , "JP Vasseur" X-OriginalArrivalTime: 18 May 2010 16:13:02.0786 (UTC) FILETIME=[FDDFEA20:01CAF6A4] Cc: roll@ietf.org Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 16:18:24 -0000 Hi Richard: Good point. Would you have a suggestion for the source route world? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Richard Kelsey > Sent: Tuesday, May 18, 2010 4:47 PM > To: JP Vasseur > Cc: roll@ietf.org > Subject: Re: [Roll] RPL Status >=20 > > From: JP Vasseur > > Date: Tue, 18 May 2010 11:47:41 +0200 > > > > Here is a quick status. First, we would like to thank the WG again for > > the continuous effort and lots of fruitful and productive work ! As > > discussed in Anaheim, the plan is still to Last Call RPL before the > > next IETF. >=20 > We will have to do something about multicasts (ticket #30). > The multicast text in the current draft has a number of limitiations; in > particular, it requires that all nodes cache DAOs. >=20 > Forwarding multicasts using unicasts makes sense if relatively few nodes > need to receive them. For a multicast that needs to get to most or all of a > network, using unicasts seems likely to be both unreliable and inefficient. >=20 > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue May 18 09:29:16 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2459328C1D6 for ; Tue, 18 May 2010 09:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.506 X-Spam-Level: X-Spam-Status: No, score=-7.506 tagged_above=-999 required=5 tests=[AWL=0.493, 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 c3nOkjrsL6tk for ; Tue, 18 May 2010 09:29:14 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 57E1B3A6C2F for ; Tue, 18 May 2010 09:22:27 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIZb8kurR7Ht/2dsb2JhbACeAXGlCZoLgnWCGwQ X-IronPort-AV: E=Sophos;i="4.53,256,1272844800"; d="scan'208";a="223019397" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 18 May 2010 16:22:07 +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 o4IGLW9b027420; Tue, 18 May 2010 16:22:07 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); Tue, 18 May 2010 18:21:59 +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: Tue, 18 May 2010 18:21:56 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01E861AF@XMB-AMS-107.cisco.com> In-Reply-To: <4BF28E02.4080000@jennic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Source Routing Header Format Thread-Index: Acr2iUxp4fQDyEXGTqKwN1mYkcZe8gAHJOrw 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> From: "Pascal Thubert (pthubert)" To: , "ROLL WG" X-OriginalArrivalTime: 18 May 2010 16:21:59.0614 (UTC) FILETIME=[3DD95DE0:01CAF6A6] Subject: Re: [Roll] Source Routing Header Format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 16:29:16 -0000 Hi Daniel: I think the aim is to have a basic header that looks like RH0 with a record route. Then 6LoWPAN can work on compressing it using 6LowpAN techniques.=20 And we'll certainly commission more work to have our own labeling system. But none of this should hold our base spec whatsoever! cheers, =20 Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Daniel Gavelle > Sent: Tuesday, May 18, 2010 2:54 PM > To: ROLL WG > Subject: Re: [Roll] Source Routing Header Format >=20 > All, >=20 > Whichever source routing header we use, it will be good if we don't need to > carry the full IPv6 address of each hop. >=20 > This is especially important when using 6LowPAN. If we don't compress the > addresses, it won't take many hops before the routing header overflows the > first 6LowPAN fragment. >=20 > Daniel. >=20 >=20 > Popa, Daniel wrote: > > Pascal, > > > > +1. It seems a good starting point. > > > > Daniel > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > >> Of Pascal Thubert (pthubert) > >> Sent: Tuesday, May 18, 2010 8:36 AM > >> To: JP Vasseur; JeongGil Ko (John) > >> Cc: ROLL WG > >> Subject: Re: [Roll] Source Routing Header Format > >> > >> Hi JP: > >> > >> For the P2P, it appears that we'll need the record route piece as well. > >> But the record route does not preexist in IPv6 standards. > >> > >> It is present in my early work on tree discovery, so in a somewhat > >> similar context of mobile routers forming networks: > >> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header > >> > >> One option to move forward could be to start from that draft and make > >> it a separate spec. > >> > >> We'd cleanup the mobility/tunnel pieces and make it fully agnostic > >> to routing protocols. > >> > >> What does the group think? > >> > >> Pascal > >> > >>> -----Original Message----- > >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > >> Of JP > >>> Vasseur > >>> Sent: Monday, May 17, 2010 2:44 PM > >>> To: JeongGil Ko (John) > >>> Cc: ROLL WG > >>> Subject: Re: [Roll] Source Routing Header Format > >>> > >>> Hi, > >>> > >>> On May 7, 2010, at 8:24 AM, JeongGil Ko (John) wrote: > >>> > >>>> Hi all, > >>>> > >>>> Have we decided on what the routing header format will be for > >> point- > >>>> to-point routing? > >>>> The last discussion that I remember concluded with "Let's do > >> something > >>>> like RH0 and do tag/labels for addressing". > >>> Right, Jonathan agreed to take the ownership of the ticket: indeed > >> the > >>> conclusion was RH0-like, staying within RPL domain to avoid security > >> issues. > >>> Labels may come next (separate ID). > >>> > >>> Thanks. > >>> > >>> JP. > >>> > >>>> Do we have anything else after that? > >>>> > >>>> -John > >>>> > >>>> ------ > >>>> JeongGil Ko (John) > >>>> Ph.D. Student > >>>> Department of Computer Science > >>>> Johns Hopkins University > >>>> http://www.cs.jhu.edu/~jgko > >>>> > >>>> _______________________________________________ > >>>> 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 > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > >=20 > -- > __________________________________________________ > Daniel Gavelle, Software Engineer > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 > Registered In England http://www.jennic.com > __________________________________________________ > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From cabo@tzi.org Tue May 18 09:39:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED5B3A6A64 for ; Tue, 18 May 2010 09:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.558 X-Spam-Level: X-Spam-Status: No, score=-5.558 tagged_above=-999 required=5 tests=[AWL=0.691, 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 WNtZvD2qQE2t for ; Tue, 18 May 2010 09:39:27 -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 613EE3A69B2 for ; Tue, 18 May 2010 09:34:05 -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 o4IGXPiY016676; Tue, 18 May 2010 18:33:25 +0200 (CEST) Received: from [192.168.217.101] (p5489A815.dip.t-dialin.net [84.137.168.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 08C85DB8E; Tue, 18 May 2010 18:33:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01E861AF@XMB-AMS-107.cisco.com> Date: Tue, 18 May 2010 18:33:24 +0200 Content-Transfer-Encoding: 7bit Message-Id: 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> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1078) Cc: ROLL WG Subject: Re: [Roll] Source Routing Header Format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 16:39:28 -0000 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. Gruesse, Carsten From prvs=747a96be7=mukul@uwm.edu Tue May 18 09:48:42 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33A743A68CF for ; Tue, 18 May 2010 09:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 zfKzy7n1aEnw for ; Tue, 18 May 2010 09:48:38 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id CB8ED3A6BCB for ; Tue, 18 May 2010 09:46:00 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 18 May 2010 11:45:53 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 375C82C3800D; Tue, 18 May 2010 11:45:53 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQ8NSMcSZI+W; Tue, 18 May 2010 11:45:52 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id EF8DA2C38011; Tue, 18 May 2010 11:45:52 -0500 (CDT) Date: Tue, 18 May 2010 11:45:52 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <723883342.12357351274201152815.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 16:48:42 -0000 Hi Philip Highly-constrained nodes, that can not afford to maintain per-neighbor state, may have no choice but to use hop-count as the metric. In any case, the reactive route discovery mechanism should not care what the routing metrics are. Note that we chose not to go deep into metrics/"routing cost" discussion in the p2p draft, simply because different people have very strong and very different opinions on what is right and what is wrong. Would you be OK with adding the following text in the description of route discovery mechanism: A node should not forward a Discovery message further if it does not have the relevant link-level cost estimates. Note that we can not really refer to the "neighbor table" as you had suggested earlier. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "Mukul Goyal" Cc: "roll" , "Emmanuel Baccelli" Sent: Tuesday, May 18, 2010 10:39:18 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 On May 17, 2010, at 11:46 PM, Mukul Goyal wrote: > [Mukul] > I agree that a node should forward a Discovery message only if it has a good estimate of the "link cost in the right direction". I guess this can be made explicit in the draft. But, the routing metric may simply be hop-count, in which case the receipt of the Discovery message is a reasonable proof of the existence of the "hop". So, I won't say that receiving a discovery packet is always insufficient to determine the "link cost" value. It really depends on the definition of the routing cost. There is extensive empirical evidence that using hopcount is a terrible idea. If the routing metric is hop-count then the LLN will not work well; you are better off routing up and down the DAG than dynamically discovering routes. The protocol can't have it both ways: argue that it quickly detects "good enough" routes with low stretch yet also needs to support detecting terrible routes. Hopcount as a metric is a myth that entered our imagination due to terrible wireless simulations. It is a simplification that does not work. Let's move past the 1990s and stop considering hopcount as something that RPL needs to accommodate. Remember, we're talking about LLNs: Lossy and Low Power Networks. Phil From jpv@cisco.com Tue May 18 09:55:21 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6223A6C6F for ; Tue, 18 May 2010 09:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.459 X-Spam-Level: X-Spam-Status: No, score=-8.459 tagged_above=-999 required=5 tests=[AWL=0.651, 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 EvrtJRYtu-qv for ; Tue, 18 May 2010 09:55:20 -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 AFA6B3A6BD1 for ; Tue, 18 May 2010 09:54:07 -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: AqYBABFj8kuQ/uCWe2dsb2JhbACeARUBARYiBhylPZoHhRAEjzw X-IronPort-AV: E=Sophos;i="4.53,256,1272844800"; d="scan'208";a="61523586" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 May 2010 16:53:58 +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 o4IGrw6X006723; Tue, 18 May 2010 16:53:58 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 18:53:58 +0200 Received: from ams-jvasseur-8716.cisco.com ([10.55.201.135]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 18:53:57 +0200 Message-Id: <5876C66D-EF59-4EAB-93BA-4C963D69D760@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <723883342.12357351274201152815.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 May 2010 18:51:57 +0200 References: <723883342.12357351274201152815.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 May 2010 16:53:58.0367 (UTC) FILETIME=[B583D6F0:01CAF6AA] Cc: Emmanuel Baccelli , roll Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 16:55:21 -0000 On May 18, 2010, at 6:45 PM, Mukul Goyal wrote: > Hi Philip > > Highly-constrained nodes, that can not afford to maintain per- > neighbor state, may have no choice but to use hop-count as the > metric. In any case, the reactive route discovery mechanism should > not care what the routing metrics are. Note that we chose not to go > deep into metrics/"routing cost" discussion in the p2p draft, I would really suggest you to refer to the metric-ID and make the P2P solution generic enough to choose the metric of choice. > simply because different people have very strong and very different > opinions on what is right and what is wrong. Would you be OK with > adding the following text in the description of route discovery > mechanism: > > A node should not forward a Discovery message further if it does not > have the relevant link-level cost estimates. > > Note that we can not really refer to the "neighbor table" as you had > suggested earlier. > > Thanks > Mukul > > ----- Original Message ----- > From: "Philip Levis" > To: "Mukul Goyal" > Cc: "roll" , "Emmanuel Baccelli" > > Sent: Tuesday, May 18, 2010 10:39:18 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll- > p2p-rpl-00 > > On May 17, 2010, at 11:46 PM, Mukul Goyal wrote: > >> [Mukul] >> I agree that a node should forward a Discovery message only if it >> has a good estimate of the "link cost in the right direction". I >> guess this can be made explicit in the draft. But, the routing >> metric may simply be hop-count, in which case the receipt of the >> Discovery message is a reasonable proof of the existence of the >> "hop". So, I won't say that receiving a discovery packet is always >> insufficient to determine the "link cost" value. It really depends >> on the definition of the routing cost. > > There is extensive empirical evidence that using hopcount is a > terrible idea. If the routing metric is hop-count then the LLN will > not work well; you are better off routing up and down the DAG than > dynamically discovering routes. The protocol can't have it both > ways: argue that it quickly detects "good enough" routes with low > stretch yet also needs to support detecting terrible routes. > > Hopcount as a metric is a myth that entered our imagination due to > terrible wireless simulations. It is a simplification that does not > work. Let's move past the 1990s and stop considering hopcount as > something that RPL needs to accommodate. Remember, we're talking > about LLNs: Lossy and Low Power Networks. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Tue May 18 09:55:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 668413A6C5B for ; Tue, 18 May 2010 09:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.459 X-Spam-Level: X-Spam-Status: No, score=-8.459 tagged_above=-999 required=5 tests=[AWL=0.651, 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 6s-M0oEQDsIv for ; Tue, 18 May 2010 09:55:44 -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 A10713A6C6C for ; Tue, 18 May 2010 09:54:16 -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: AqYBABFj8kuQ/uCWe2dsb2JhbACeARUBARYiBhylPZoHhRAEjzw X-IronPort-AV: E=Sophos;i="4.53,256,1272844800"; d="scan'208";a="61523604" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 May 2010 16:54: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 o4IGs7pV006756; Tue, 18 May 2010 16:54:07 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 18:54:07 +0200 Received: from ams-jvasseur-8716.cisco.com ([10.55.201.135]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 18:54:06 +0200 Message-Id: From: JP Vasseur To: Mukul Goyal In-Reply-To: <723883342.12357351274201152815.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 May 2010 18:54:06 +0200 References: <723883342.12357351274201152815.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 May 2010 16:54:07.0117 (UTC) FILETIME=[BABAFBD0:01CAF6AA] Cc: Emmanuel Baccelli , roll Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 16:55:44 -0000 On May 18, 2010, at 6:45 PM, Mukul Goyal wrote: > Hi Philip > > Highly-constrained nodes, that can not afford to maintain per- > neighbor state, may have no choice but to use hop-count as the > metric. In any case, the reactive route discovery mechanism should > not care what the routing metrics are. Note that we chose not to go > deep into metrics/"routing cost" discussion in the p2p draft, I would really suggest you to refer to the metric-ID and make the P2P solution generic enough to choose the metric of choice. > simply because different people have very strong and very different > opinions on what is right and what is wrong. Would you be OK with > adding the following text in the description of route discovery > mechanism: > > A node should not forward a Discovery message further if it does not > have the relevant link-level cost estimates. > > Note that we can not really refer to the "neighbor table" as you had > suggested earlier. > > Thanks > Mukul > > ----- Original Message ----- > From: "Philip Levis" > To: "Mukul Goyal" > Cc: "roll" , "Emmanuel Baccelli" > > Sent: Tuesday, May 18, 2010 10:39:18 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll- > p2p-rpl-00 > > On May 17, 2010, at 11:46 PM, Mukul Goyal wrote: > >> [Mukul] >> I agree that a node should forward a Discovery message only if it >> has a good estimate of the "link cost in the right direction". I >> guess this can be made explicit in the draft. But, the routing >> metric may simply be hop-count, in which case the receipt of the >> Discovery message is a reasonable proof of the existence of the >> "hop". So, I won't say that receiving a discovery packet is always >> insufficient to determine the "link cost" value. It really depends >> on the definition of the routing cost. > > There is extensive empirical evidence that using hopcount is a > terrible idea. If the routing metric is hop-count then the LLN will > not work well; you are better off routing up and down the DAG than > dynamically discovering routes. The protocol can't have it both > ways: argue that it quickly detects "good enough" routes with low > stretch yet also needs to support detecting terrible routes. > > Hopcount as a metric is a myth that entered our imagination due to > terrible wireless simulations. It is a simplification that does not > work. Let's move past the 1990s and stop considering hopcount as > something that RPL needs to accommodate. Remember, we're talking > about LLNs: Lossy and Low Power Networks. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=747a96be7=mukul@uwm.edu Tue May 18 10:13:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11CB53A6A66 for ; Tue, 18 May 2010 10:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=0.349, 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 i-kDOsAzHC19 for ; Tue, 18 May 2010 10:13:12 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 4C8AD3A67CF for ; Tue, 18 May 2010 10:12:28 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 18 May 2010 12:12:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 8CD892C3800F; Tue, 18 May 2010 12:12:15 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbE3IarCuYHP; Tue, 18 May 2010 12:12:10 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 823202C38016; Tue, 18 May 2010 12:12:10 -0500 (CDT) Date: Tue, 18 May 2010 12:12:10 -0500 (CDT) From: Mukul Goyal To: JP Vasseur Message-ID: <1952937910.12377401274202730439.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <5876C66D-EF59-4EAB-93BA-4C963D69D760@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: Emmanuel Baccelli , roll Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 17:13:14 -0000 Hi JP, > Hi Philip > > Highly-constrained nodes, that can not afford to maintain per- > neighbor state, may have no choice but to use hop-count as the > metric. In any case, the reactive route discovery mechanism should > not care what the routing metrics are. Note that we chose not to go > deep into metrics/"routing cost" discussion in the p2p draft, [JP] I would really suggest you to refer to the metric-ID and "make the P2P solution generic enough to choose the metric of choice". [Mukul] This is exactly the intent. I will add reference to the metrics ID. Thanks Mukul > simply because different people have very strong and very different > opinions on what is right and what is wrong. Would you be OK with > adding the following text in the description of route discovery > mechanism: > > A node should not forward a Discovery message further if it does not > have the relevant link-level cost estimates. > > Note that we can not really refer to the "neighbor table" as you had > suggested earlier. > > Thanks > Mukul > > ----- Original Message ----- > From: "Philip Levis" > To: "Mukul Goyal" > Cc: "roll" , "Emmanuel Baccelli" > > Sent: Tuesday, May 18, 2010 10:39:18 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll- > p2p-rpl-00 > > On May 17, 2010, at 11:46 PM, Mukul Goyal wrote: > >> [Mukul] >> I agree that a node should forward a Discovery message only if it >> has a good estimate of the "link cost in the right direction". I >> guess this can be made explicit in the draft. But, the routing >> metric may simply be hop-count, in which case the receipt of the >> Discovery message is a reasonable proof of the existence of the >> "hop". So, I won't say that receiving a discovery packet is always >> insufficient to determine the "link cost" value. It really depends >> on the definition of the routing cost. > > There is extensive empirical evidence that using hopcount is a > terrible idea. If the routing metric is hop-count then the LLN will > not work well; you are better off routing up and down the DAG than > dynamically discovering routes. The protocol can't have it both > ways: argue that it quickly detects "good enough" routes with low > stretch yet also needs to support detecting terrible routes. > > Hopcount as a metric is a myth that entered our imagination due to > terrible wireless simulations. It is a simplification that does not > work. Let's move past the 1990s and stop considering hopcount as > something that RPL needs to accommodate. Remember, we're talking > about LLNs: Lossy and Low Power Networks. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Tue May 18 10:17:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE983A69AA for ; Tue, 18 May 2010 10:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 Vl3RGNBG4lyk for ; Tue, 18 May 2010 10:17:53 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 6C31A28C189 for ; Tue, 18 May 2010 10:15:43 -0700 (PDT) Received: from dnab4046bc.stanford.edu ([171.64.70.188]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OEQOG-0001A3-1O; Tue, 18 May 2010 10:15:36 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <723883342.12357351274201152815.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Tue, 18 May 2010 10:15:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6BFB5457-6D73-4478-B7BD-750B12BD166A@cs.stanford.edu> References: <723883342.12357351274201152815.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1078) X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621 Cc: roll , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 17:17:54 -0000 On May 18, 2010, at 9:45 AM, Mukul Goyal wrote: > Note that we chose not to go deep into metrics/"routing cost" = discussion in the p2p draft, simply because different people have very = strong and very different opinions on what is right and what is wrong.=20= I'm sorry; I need to argue this point. This isn't a question of opinion. = It's a question of overwhelming scientific evidence and deployment = experiences from real networks. Here are two simple published = studies[1,2]. Does anyone have a positive, successful, deployment example of = hopcount-based routing which does not filter usable "hopcount" links = based on link estimates? That being said, > A node should not forward a Discovery message further if it does not = have the relevant link-level cost estimates. I think that is this is changed to MUST NOT, then it could be OK. Or how = about "A node MUST NOT forward a Discovery message from a node for which it = does not have relevant link-level metric information." > Note that we can not really refer to the "neighbor table" as you had = suggested earlier. Why? Phil [1] Deepak Ganesan et al. "Complex Behavior at Scale: An Experimental = Study of Low-Power Wireless Sensor Networks."=20 [2] Douglas S. J. De Couto et al. "A high-throughput path metric for = multi-hop wireless routing." From prvs=747a96be7=mukul@uwm.edu Tue May 18 10:43:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1814928C19F for ; Tue, 18 May 2010 10:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 9baiPEg-XJ0v for ; Tue, 18 May 2010 10:43:23 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id EC21E3A6C91 for ; Tue, 18 May 2010 10:41:16 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 18 May 2010 12:41:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 69EB72C38014; Tue, 18 May 2010 12:41:09 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uX--c9xnQw6F; Tue, 18 May 2010 12:41:09 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 237612C38013; Tue, 18 May 2010 12:41:09 -0500 (CDT) Date: Tue, 18 May 2010 12:41:09 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <352039149.12399081274204469006.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <395220985.12390651274203798673.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 17:43:24 -0000 Philip >> Note that we chose not to go deep into metrics/"routing cost" discussion in the p2p draft, simply because different people have very strong and very different opinions on what is right and what is wrong. >I'm sorry; I need to argue this point. This isn't a question of opinion. It's a question of overwhelming scientific evidence and deployment experiences from real networks. Here are two simple published studies[1,2]. You are ignoring the fact that there are scenarios (especially, in home automation environment; Anders may back me up on this), where a device can not maintain any neighbor-specific state (e.g. the cost of the link to the neighbor or even the identity of the neighbor). You can not argue that hop-count should not be used even in such situations. It may be a bad metric in general but it may still be the only metric that can be used in a given situation. >> A node should not forward a Discovery message further if it does not have the relevant link-level cost estimates. >I think that is this is changed to MUST NOT, then it could be OK. Or how about "A node MUST NOT forward a Discovery message from a node for which it does not have relevant link-level metric information." I am OK with changing "should not" to "MUST NOT". There is a problem with the text you suggested. Suppose a _forward_ route is being discovered as per a certain routing metric. Node B receives a discovery message from node A. As per your text, node B must not forward the message further if cost B->A is unavailable/bad. But, cost B->A is irrelevant in this case. Your text assumes that routing metrics are symmetrical enough to conclude that link A->B must be bad if link B->A is bad. Whether this assumption is valid or not depends on the definition of the routing metric/cost and is not some thing that should concern the route discovery protocol. The route discovery protocol needs to be agnostic about the metrics being used. Would you be OK with the text I suggested with "MUST NOT" replacing "should not": A node MUST NOT forward a Discovery message further if it does not have the relevant link-level cost estimates. >> Note that we can not really refer to the "neighbor table" as you had suggested earlier. >Why? Because, a neighbor table may not exist since nodes are too constrained to maintain per-neighbor states. Thanks Mukul From richard.kelsey@ember.com Tue May 18 11:11:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89E23A6B8B for ; Tue, 18 May 2010 11:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.863 X-Spam-Level: X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[AWL=-0.123, 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 XCom1yScKxts for ; Tue, 18 May 2010 11:11:34 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id F3E903A68D5 for ; Tue, 18 May 2010 11:11:27 -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); Tue, 18 May 2010 14:14:45 -0400 Date: Tue, 18 May 2010 14:10:50 -0400 Message-Id: <87ljbhytat.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D01E861A6@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D01E861A6@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 18 May 2010 18:14:45.0972 (UTC) FILETIME=[FEE9A940:01CAF6B5] Cc: roll@ietf.org Subject: [Roll] RPL multicast (was Re: RPL Status) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 18:11:35 -0000 > Date: Tue, 18 May 2010 18:12:59 +0200 > From: "Pascal Thubert (pthubert)" > > > Richard Kelsey > > Sent: Tuesday, May 18, 2010 4:47 PM > > > > We will have to do something about multicasts (ticket #30). > > The multicast text in the current draft has a number of limitiations; > > in particular, it requires that all nodes cache DAOs. > > > > Forwarding multicasts using unicasts makes sense if relatively few > > nodesneed to receive them. For a multicast that needs to get to > > most or all of a network, using unicasts seems likely to be both > > unreliable and inefficient. > Good point. Would you have a suggestion for the source route world? Pascal, It's a hard problem. ZigBee, which has always-on routers, uses hop-limited flooding for multicasts. This works well for multicasts that need to go to all or almost all nodes. I do not know how multicasts are handled in sensor networks, where flooding is relatively expensive. In the source route world, for multicasts with few subscribers, the simplest thing would to use DAOs more-or-less as is done for downward routes. MLD requests would be forwarded up to the root, and the root would keep track of which nodes were subscribed to which multicast addresses. Multicasts would be also forwarded to the root, which would unicast them down to subscribers. I suppose the root could also make the determination as to which multicasts could be more effectively flooded. More complicated schemes are possible, but I don't like more complicated schemes :-). -Richard Kelsey From prvs=747a96be7=mukul@uwm.edu Tue May 18 14:54:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516743A69B7 for ; Tue, 18 May 2010 14:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=0.048, 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 g7oO855QnFhw for ; Tue, 18 May 2010 14:54:17 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 2F4323A698F for ; Tue, 18 May 2010 14:54:17 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 18 May 2010 16:54:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9F6D22C3800F; Tue, 18 May 2010 16:54:09 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD+b8YfZ8i36; Tue, 18 May 2010 16:54:09 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 6C4642C3800E; Tue, 18 May 2010 16:54:09 -0500 (CDT) Date: Tue, 18 May 2010 16:54:09 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <52410827.12575211274219649358.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2010862516.12572171274219252310.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll WG , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 21:54:18 -0000 Hi Philip, JP Here is a list of the controls that can be used to limit the spread of discovery messages: 1. If a node does not know the link cost, it wont forward the discovery message further (was implicit in the p2p draft; now would be made explicit); 2. If a node receives a discovery message advertizing a rank (in the temporary DAG) higher than the node's current rank, the discovery message is ignored; 3. If the discovery message has already traveled a certain "distance" (determined based on the rank that the receiving node would achieve in the temporary DAG using the rank advertized in the discovery message), it wont be forwarded any further; 4. If the end-to-end cost for the path taken by the discovery message so far already fails the "good enough" criteria, the discovery message is not forwarded any further; (this control is optional since the "good enough" criteria may be too difficult for a constrained intermediate node to calculate) 5. The trickle timer. The trickle timer helps control the spread of discovery messages in following ways: 1. The timer's interval can be chosen to "speed up" the discovery message or "slow it" down; the tradeoff being the number of discovery messages generated. A large interval allows only one message to be sent in response to several received. 2. The redundancy threshold of the trickle timer can optionally be used to further limit the generation of discovery messages. Do not generate your own discovery message if you have already received "n" messages advertizing the same/better rank or e2e cost than what you will advertize. I guess a node could also employ a local policy regarding when and how many times to generate a discovery message: 1. generate discovery messages only a certain number of times; 2. do not generate a discovery message at the timer's firing if the rank/cost to be advertized is same as before; 2. always generate a discovery message at the timer's firing (irrespective of the redundancy threshold) if the new cost/rank to be advertized is better than before. So, to answer your question: "are you suggesting using Trickle as the route discovery mechanism, or as the data delivery mechanism? " I would say that we are using trickle as an additional control over the generation of discovery messages. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "JP Vasseur" Cc: "Mukul Goyal" , "Anders Brandt" , "roll WG" , "Emmanuel Baccelli" Sent: Tuesday, May 18, 2010 10:36:46 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 On May 18, 2010, at 2:24 AM, JP Vasseur wrote: [Anders] I understand your concern and if you have resources in a node for doing more intelligent forwarding decisions, this is wonderful. For the most constrained nodes, however, I love the simplicity of Trickle where you forward (randomized schedule) as long as you have picked up less than n copies of the discovery message from you direct range neighbors. But that requires to be cautious too since that could eliminate some "good" paths too, and in particular the ones that are better than the DODAG path. Anders -- are you suggesting using Trickle as the route discovery mechanism, or as the data delivery mechanism? Phil From samitac@ipinfusion.com Tue May 18 16:56:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D237E3A6A08 for ; Tue, 18 May 2010 16:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[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 W+Am-mPp44yS for ; Tue, 18 May 2010 16:56:54 -0700 (PDT) Received: from smtp109.sbc.mail.gq1.yahoo.com (smtp109.sbc.mail.gq1.yahoo.com [67.195.14.39]) by core3.amsl.com (Postfix) with SMTP id 0ACFC3A6765 for ; Tue, 18 May 2010 16:56:54 -0700 (PDT) Received: (qmail 22563 invoked from network); 18 May 2010 23:56:46 -0000 Received: from (samitac@65.223.109.250 with login) by smtp109.sbc.mail.gq1.yahoo.com with SMTP; 18 May 2010 16:56:46 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: uMk6DIgVM1l1d5u6itSy1PiwhS9busP3ZSk.G.DXQIcOylnLAEHhUYfDZqdR9IiyFcxjaBuXw5p.vdwPbpJwJ1rIhO5C9IUkRNxyrCLSZ3_Upzxbqu63KIA9r56XD4I.XT0AdwUrQVmXc3NuxbZYEE5CAKownQBGAM5oTJUngddPS5GmmrsyrZk_yInE3j4TUxWmBFlQ4zBNnTIh8NUqkzIq2rPgbeToRdu7Bnm8iFrgDsA4gS2PowcPyRedG6Iy X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Richard Kelsey'" , "'JP Vasseur'" References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> Date: Tue, 18 May 2010 16:56:43 -0700 Message-ID: <028401caf6e5$c5592d60$500b8820$@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: Acr2mUKG1dli71ngQ3+dnRVKOvz6YgARsbGw Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 23:56:54 -0000 Hi Richard/JP, > > > > Here is a quick status. First, we would like to thank the WG again for > > the continuous effort and lots of fruitful and productive work ! As > > discussed in Anaheim, the plan is still to Last Call RPL before the > > next IETF. > > We will have to do something about multicasts (ticket #30). > The multicast text in the current draft has a number of limitiations; in > particular, it requires that all nodes cache DAOs. > [SC>] Ticket #30 is about clarification of text regarding the multicast operation. Indeed it is not clear and subject to implementor's interpretation. > Forwarding multicasts using unicasts makes sense if relatively few nodes > need to receive them. For a multicast that needs to get to most or all of a > network, using unicasts seems likely to be both unreliable and inefficient. > [SC>] BTW, is RPL also trying to solve multicast routing/forwarding completely in all cases ? It might be better to have another id for the detailed multicast forwarding/routing for all cases (multicast to all nodes in LLN, multicast to nodes that are spread out under different parents far from each other and trying communicate with each other etc.). It might be easier for RPL draft to handle a set of common use cases with the existing mechanism. I wonder what would be the typical applications today for RPL in LLN ? Is it in the building network where most of the communication takes place from one or two parent or grand-parent nodes to their descendants using a multi-cast address? That said, we also need to make sure the current multicast mechanism could be extended to cover other scenarios. Actually the current solution of using DAO to store the multicast address and the corresponding members of the multicast address may work out. But I agree it is more work on each parent node to aggregate the multicast addresses, process them and store them and might also make a decision to prune. If we consider LLN to be a route-over only link, then modifying MLD hop-limit and forwarding MLD messages are an option but we still need to consider pruning. A generic solution for multicast routing/forwarding in LLN seems to be a non-trivial problem to be handled in RPL draft alone. Thanks, -Samita From abr@sdesigns.dk Wed May 19 00:32:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3693A6B40 for ; Wed, 19 May 2010 00:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.364 X-Spam-Level: X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_50=0.001, SARE_MILLIONSOF=0.315] 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 NE8sgyG-4w4X for ; Wed, 19 May 2010 00:32: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 3F0EA3A6BC2 for ; Wed, 19 May 2010 00:26:04 -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, 19 May 2010 09:25:55 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A173@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 Thread-Index: Acr2ow0nb4dyMVPTTxajNS1SMKfVmgAfxAfQ References: <463402115.12177031274165176659.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Anders Brandt" To: "Philip Levis" , "Mukul Goyal" Cc: roll , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 07:32:44 -0000 hi Phil > There is extensive empirical evidence that using hopcount is a terrible idea. [Anders]=20 That may very well be. I suggest we put that terrible idea next to the extensive evidence that several commercial systems works _GOOD_ENOUGH_ with simple hop-count COMBINED with the ability to find another route if there is a substantial number of retransmissions on that actual route. The result is terribly inexpensive chips (< $2) with radio, RAM, CPU and everything onboard. Consumers want this! >If the routing metric is hop-count then the LLN will not work well; > you are better off routing up and down the DAG [Anders]=20 With these small nodes, the only DAG information maintained in individual nodes is the DODAGID + source routes a few other nodes that the node is supposed to control in some way. Yes, then there are some few nodes which can do a "Turn a lot of nodes off". They will have more RAM + non-volatile memory but we SHOULD NOT put that burden on all nodes in the network. (sorry for SHOUTING but we should really not ignore the extensive evidence of the successfull deployment of millions of these extemely inexpensive chips out there) > The protocol can't have it both ways: argue that it quickly detects "good enough" routes with low stretch yet also needs to > support detecting terrible routes. =20 [Anders]=20 The nice thing about the P2P ID proposal is that you can specify in the discovery if you are in a hurry and just want the first route that can turn on your lamp or if you are on a quest for "good" routes; i.e. can live with having to wait for a number of discovery responses before you pick the best - out of your metrics criteria. Cheers, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Philip Levis > Sent: Tuesday, May 18, 2010 17:39 > To: Mukul Goyal > Cc: roll; Emmanuel Baccelli > Subject: Re: [Roll] Fwd: New Version Notification=20 > fordraft-dt-roll-p2p-rpl-00 >=20 > On May 17, 2010, at 11:46 PM, Mukul Goyal wrote: >=20 > > [Mukul] > > I agree that a node should forward a Discovery message only=20 > if it has a good estimate of the "link cost in the right=20 > direction". I guess this can be made explicit in the draft.=20 > But, the routing metric may simply be hop-count, in which=20 > case the receipt of the Discovery message is a reasonable=20 > proof of the existence of the "hop". So, I won't say that=20 > receiving a discovery packet is always insufficient to=20 > determine the "link cost" value. It really depends on the=20 > definition of the routing cost. >=20 > There is extensive empirical evidence that using hopcount is=20 > a terrible idea. If the routing metric is hop-count then the=20 > LLN will not work well; you are better off routing up and=20 > down the DAG than dynamically discovering routes. The=20 > protocol can't have it both ways: argue that it quickly=20 > detects "good enough" routes with low stretch yet also needs=20 > to support detecting terrible routes.=20 >=20 > Hopcount as a metric is a myth that entered our imagination=20 > due to terrible wireless simulations. It is a simplification=20 > that does not work. Let's move past the 1990s and stop=20 > considering hopcount as something that RPL needs to=20 > accommodate. Remember, we're talking about LLNs: Lossy and=20 > Low Power Networks. >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From abr@sdesigns.dk Wed May 19 00:37:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34EF3A6BE3 for ; Wed, 19 May 2010 00:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[AWL=-0.495, 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 bzej+mZOYQrL for ; Wed, 19 May 2010 00:37:17 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id EBAAB28C152 for ; Wed, 19 May 2010 00:31:09 -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_01CAF725.3BC6B2AC" Date: Wed, 19 May 2010 09:31:02 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A174@zensys17.zensys.local> In-Reply-To: <1420C792-ACE0-481A-86A0-D5578A165470@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 Thread-Index: Acr2owFR32EbFvOJRJ2usKCw8akH0wAgYjvA References: <2099818134.12176841274164916968.JavaMail.root@mail02.pantherlink.uwm.edu> <463402115.12177031274165176659.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E0142A165@zensys17.zensys.local> <2E80D99C-9328-439C-B981-2E29A904E913@cisco.com> <1420C792-ACE0-481A-86A0-D5578A165470@cs.stanford.edu> From: "Anders Brandt" To: "Philip Levis" , "JP Vasseur" Cc: roll WG , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 07:37:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF725.3BC6B2AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil ________________________________ From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: Tuesday, May 18, 2010 17:37 To: JP Vasseur Cc: Mukul Goyal; Anders Brandt; roll WG; Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 =09 =09 =09 =09 On May 18, 2010, at 2:24 AM, JP Vasseur wrote: =09 =09 =09 [Anders] I understand your concern and if you have resources =09 in a node for doing more intelligent forwarding decisions, this =09 is wonderful. =09 For the most constrained nodes, however, I love the simplicity =09 of Trickle where you forward (randomized schedule) as long as =09 you have picked up less than n copies of the discovery message =09 from you direct range neighbors. =09 But that requires to be cautious too since that could eliminate some "good" paths too, and in particular the ones that are better than the DODAG path. =09 Anders -- are you suggesting using Trickle as the route discovery mechanism, or as the data delivery mechanism?=20 [Anders] The data delivery mechanism which can ramdomly schedule the forwarding of discovery requests and stop doing that if a number of other nodes already did forward a copy of the same frame in the direct range neighborhood. (Admitted - it is a long time ago I actually did read the Trickle paper but this is how I remember the mechanism (?) ) =20 - Anders =09 =09 =09 Phil ------_=_NextPart_001_01CAF725.3BC6B2AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Phil

From: Philip Levis=20 [mailto:pal@cs.stanford.edu]
Sent: Tuesday, May 18, 2010=20 17:37
To: JP Vasseur
Cc: Mukul Goyal; Anders = Brandt; roll=20 WG; Emmanuel Baccelli
Subject: Re: [Roll] Fwd: New Version=20 Notification fordraft-dt-roll-p2p-rpl-00


On May 18, 2010, at 2:24 AM, JP Vasseur wrote:


[Anders] I understand your concern and if = you have=20 resources
in a node for doing more intelligent = forwarding=20 decisions, this
is wonderful.
For the most constrained nodes, however, I = love=20 the simplicity
of Trickle where you forward (randomized = schedule)=20 as long as
you have picked up less than n copies of = the=20 discovery message
from you direct range=20 neighbors.

But that requires to be cautious too = since=20 that could eliminate some "good" paths too, and
in particular the = ones=20 that are better than the DODAG = path.

Anders -- are you suggesting using Trickle as the route discovery = mechanism, or as the data delivery mechanism? 
[Anders]
The data delivery mechanism which can ramdomly schedule the=20 forwarding of = discovery=20 requests and stop doing that if a number
of other nodes already did = forward a=20 copy of the same frame in the direct range = neighborhood.
(Admitted - it is a long time ago I actually did read the = Trickle paper=20 but this is how I remember the mechanism (?)   =20 )
 
- Anders

Phil
------_=_NextPart_001_01CAF725.3BC6B2AC-- From abr@sdesigns.dk Wed May 19 00:45:17 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743E43A6BF0 for ; Wed, 19 May 2010 00:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.473 X-Spam-Level: X-Spam-Status: No, score=-0.473 tagged_above=-999 required=5 tests=[AWL=-0.475, 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 DMYxM6ki-QX6 for ; Wed, 19 May 2010 00:45:16 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id E56453A6C21 for ; Wed, 19 May 2010 00:39:51 -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_01CAF726.72DDA7EA" Date: Wed, 19 May 2010 09:39:44 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A175@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Status Thread-Index: Acr2bzqPWxPN57CbQt+h7yszz74kKgAti/sw References: From: "Anders Brandt" To: "JP Vasseur" , "roll WG" Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 07:45:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF726.72DDA7EA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 >the plan is still to Last Call RPL before the next IETF =20 I would like to poll the WG on this statement. The home and building requirements are not met by the current RPL draft and we have not even started discussing the P2P ID mechanisms in detail - or frame format modifications for that matter. =20 Does the WG agree that a RPL spec without support for home and building applications is acceptable? =20 Thanks, Anders ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Tuesday, May 18, 2010 11:48 To: roll WG Subject: [Roll] RPL Status =09 =09 Dear WG,=20 =09 =09 Here is a quick status. First, we would like to thank the WG again for the continuous effort and lots of fruitful and productive work ! As discussed in Anaheim, the plan is still to Last Call RPL before the next IETF. The plan is to release the next revision of the RPL I-D by end of next week. Rev-08 will address the following: 1) Security section (integrating the work on the security DT) 2) New DAO mechanism (cleaner and more simple), as agreed on the Mailing List 3) Basic source routing =3D> See also companion drafts to be published very soon for (RH-0 like) 4) Updated manageability section 5) DAO ACK 6) Trickle algorithm removed from the core specification (in a separate doc), Examples removed 7) Several Edits, clarifications, ...=20 I had a discussion with David, and the plan is to have the P2P a separate ID (the current RPL specification provides basic P2P, with "advanced" P2P defined in that I-D), with the objective to progress both documents in parallel.=20 What else ? We need to progress a few other documents: 1) Use of the RPL TLV: see draft-hui-6man-rpl-option (6man WG) 2) Source routing header (RH-0 like): to be published soon (Jonathan/David) 3) RPL Variables (ticket #22) 4) ID related to measurement from P2P (if consensus on Mailing list) Looking forward to your comments as soon as rev-08 will be published. Thanks. JP and David. ------_=_NextPart_001_01CAF726.72DDA7EA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
>the plan is still to = Last Call RPL=20 before the next IETF
 
I=20 would like to poll the WG on this = statement.
The home and = building=20 requirements are not met by the current RPL draft and we have not even = started=20 discussing the P2P ID mechanisms in detail = -
or frame format modifications for that=20 matter.
 
Does the WG agree that a RPL spec without = support for=20 home and building applications is=20 acceptable?
 
Thanks,
 =20 Anders

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent:=20 Tuesday, May 18, 2010 11:48
To: roll WG
Subject: = [Roll]=20 RPL Status

Dear WG,

Here is a quick status. First, we would like to thank the WG = again for=20 the continuous effort and lots of fruitful and productive work ! As = discussed=20 in Anaheim, the plan is still to Last Call RPL before the next IETF. = The plan=20 is to release the next revision of the RPL I-D by end of next week. = Rev-08=20 will  address the following:

1) Security section (integrating the work on the security = DT)
2) New DAO mechanism (cleaner and more simple), as agreed on=20 the Mailing List
3) Basic source routing  =3D> See also companion drafts = to be=20 published very soon for (RH-0 like)
4) Updated manageability section
5) DAO ACK
6) Trickle algorithm removed from the core specification (in a = separate=20 doc), Examples removed
7) Several Edits, clarifications, ... 

I had a discussion with David, and the plan is to have the P2P a = separate=20 ID (the current RPL specification provides basic P2P, with "advanced" = P2P=20 defined in that I-D), with the objective to progress both documents in = parallel. 

What else ?
We need to progress a few other documents:
1) Use of the RPL TLV: see draft-hui-6man-rpl-option (6man = WG)
2) Source routing header (RH-0 like): to be published soon=20 (Jonathan/David)
3) RPL Variables (ticket #22)
4) ID related to measurement from P2P (if consensus on Mailing=20 list)

Looking forward to your comments as soon as rev-08 will be=20 published.

Thanks.

JP and David.
------_=_NextPart_001_01CAF726.72DDA7EA-- From trac@tools.ietf.org Wed May 19 04:51:53 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26153A6BBC for ; Wed, 19 May 2010 04:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.163 X-Spam-Level: X-Spam-Status: No, score=-101.163 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_40=-0.185, 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 9qLL+suN6a7L for ; Wed, 19 May 2010 04:51:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D8A1A3A6B92 for ; Wed, 19 May 2010 04:51:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OEhnq-0002P0-Jo; Wed, 19 May 2010 04:51:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Wed, 19 May 2010 11:51:10 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/26#comment:1 Message-ID: <064.20bfdd0d8caa0a55807bd32b9ad8eda9@tools.ietf.org> References: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@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: roll@ietf.org Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 11:51:53 -0000 #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: task | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: From Tim Winter There was a WG consensus in this thread: http://www.ietf.org/mail-archive/web/roll/current/msg03562.html The summary text would be: The approach is to signal the mode of operation through the DIO, that all nodes MUST be capable to support a non-storing mode of operation, and that nodes who are incapable of acting as routers in a storing mode may participate in the DODAG as hosts (leaves). (The suitable behavior when a routing table in a storing node becomes saturated is still under consideration). -- Ticket URL: roll From pthubert@cisco.com Wed May 19 06:00:16 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69BE43A6AC9 for ; Wed, 19 May 2010 06:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.514 X-Spam-Level: X-Spam-Status: No, score=-7.514 tagged_above=-999 required=5 tests=[AWL=0.485, 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 va0C50bd0aLo for ; Wed, 19 May 2010 06:00:15 -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 B22883A6968 for ; Wed, 19 May 2010 05:59:38 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,263,1272844800"; d="scan'208";a="199527810" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 19 May 2010 12:59:31 +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 o4JCxIYl005803; Wed, 19 May 2010 12:59:31 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); Wed, 19 May 2010 14:59: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: Wed, 19 May 2010 14:59:12 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01E86506@XMB-AMS-107.cisco.com> In-Reply-To: <87ljbhytat.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPL multicast (was Re: [Roll] RPL Status) Thread-Index: Acr2tYdq9+YzZlAGTN+D5AAY3KskhgAm7t9Q References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D01E861A6@XMB-AMS-107.cisco.com> <87ljbhytat.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 19 May 2010 12:59:26.0251 (UTC) FILETIME=[1C4B17B0:01CAF753] Cc: roll@ietf.org Subject: Re: [Roll] RPL multicast (was Re: RPL Status) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 13:00:16 -0000 Hi Richard: MLD requests are effectively turned into DAOs and will reach the root as you suggest. From there, what do we do in source route? The extremes (global flood/prune and as many unicast from the root) seem both quite easy and quite expansive when applied to the wrong case. Pruning will require states in the nodes to retain information on the floods it has already seen and passed along. Certainly we can leave it up to the root to select either method based on the density of listeners. A real multicast operation in the intermediate nodes in pure source route would require a new form of RH encoding, that's doable but not necessarily trivial. Would we want that in the RH spec? Finally, if the direction for the future is states in some nodes as we used to have it, then those can effectively multicast for their subtrees, so maybe we can keep that piece for later... What do you think? Pascal > -----Original Message----- > From: Richard Kelsey [mailto:richard.kelsey@ember.com] > Sent: Tuesday, May 18, 2010 8:11 PM > To: Pascal Thubert (pthubert) > Cc: jpv@cisco.com; roll@ietf.org > Subject: RPL multicast (was Re: [Roll] RPL Status) >=20 > > Date: Tue, 18 May 2010 18:12:59 +0200 > > From: "Pascal Thubert (pthubert)" > > > > > Richard Kelsey > > > Sent: Tuesday, May 18, 2010 4:47 PM > > > > > > We will have to do something about multicasts (ticket #30). > > > The multicast text in the current draft has a number of > > > limitiations; in particular, it requires that all nodes cache DAOs. > > > > > > Forwarding multicasts using unicasts makes sense if relatively few > > > nodesneed to receive them. For a multicast that needs to get to > > > most or all of a network, using unicasts seems likely to be both > > > unreliable and inefficient. >=20 > > Good point. Would you have a suggestion for the source route world? >=20 > Pascal, >=20 > It's a hard problem. >=20 > ZigBee, which has always-on routers, uses hop-limited flooding for > multicasts. This works well for multicasts that need to go to all or almost all > nodes. >=20 > I do not know how multicasts are handled in sensor networks, where > flooding is relatively expensive. >=20 > In the source route world, for multicasts with few subscribers, the simplest > thing would to use DAOs more-or-less as is done for downward routes. MLD > requests would be forwarded up to the root, and the root would keep track > of which nodes were subscribed to which multicast addresses. Multicasts > would be also forwarded to the root, which would unicast them down to > subscribers. I suppose the root could also make the determination as to > which multicasts could be more effectively flooded. >=20 > More complicated schemes are possible, but I don't like more complicated > schemes :-). > -Richard Kelsey From richard.kelsey@ember.com Wed May 19 07:53:27 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D980E3A66B4 for ; Wed, 19 May 2010 07:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[AWL=-0.393, 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 hJMVkbViYXei for ; Wed, 19 May 2010 07:53:27 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 655C43A6C4D for ; Wed, 19 May 2010 07:52:29 -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); Wed, 19 May 2010 10:55:48 -0400 Date: Wed, 19 May 2010 10:51:42 -0400 Message-Id: <87hbm4ymf5.fsf@kelsey-ws.hq.ember.com> To: "Samita Chakrabarti" In-reply-to: <028401caf6e5$c5592d60$500b8820$@com> (samitac@ipinfusion.com) From: Richard Kelsey References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> X-OriginalArrivalTime: 19 May 2010 14:55:48.0743 (UTC) FILETIME=[5E2ED170:01CAF763] Cc: roll@ietf.org Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 14:53:27 -0000 > From: "Samita Chakrabarti" > Date: Tue, 18 May 2010 16:56:43 -0700 > > [SC>] BTW, is RPL also trying to solve multicast > routing/forwarding completely in all cases? It might be > better to have another id for the detailed multicast > forwarding/routing for all cases (multicast to all nodes > in LLN, multicast to nodes that are spread out under > different parents far from each other and trying > communicate with each other etc.). RPL is required to provide multicast routing/forwarding. I would assume that it has to handle all cases, although clearly it need not handle them with equal efficiency. Ideally RPL's handling of multicasts would be more or less on par with its handling of unicasts. In particular, the rules for handling DAOs and DAO caching should not change too much for multicast addresses. As with unicasts, specialized implementations for particular situations should go in other documents. Exactly where to draw the line is open to debate. -Richard Kelsey From richard.kelsey@ember.com Wed May 19 08:06:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD263A681D for ; Wed, 19 May 2010 08:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[AWL=-0.461, 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 iBlJcOXYo4Dr for ; Wed, 19 May 2010 08:06:02 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id E98483A68C5 for ; Wed, 19 May 2010 08:05: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); Wed, 19 May 2010 11:09:18 -0400 Date: Wed, 19 May 2010 11:05:11 -0400 Message-Id: <87fx1oylso.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D01E86506@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D01E861A6@XMB-AMS-107.cisco.com> <87ljbhytat.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D01E86506@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 19 May 2010 15:09:18.0790 (UTC) FILETIME=[41022E60:01CAF765] Cc: roll@ietf.org Subject: Re: [Roll] RPL multicast (was Re: RPL Status) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 15:06:03 -0000 > Date: Wed, 19 May 2010 14:59:12 +0200 > From: "Pascal Thubert (pthubert)" > > MLD requests are effectively turned into DAOs and will reach the root as > you suggest. From there, what do we do in source route? > > The extremes (global flood/prune and as many unicast from the root) seem > both quite easy and quite expansive when applied to the wrong case. Yes. I think that both will have to be available, at least in some networks. > Pruning will require states in the nodes to retain information on the > floods it has already seen and passed along. Yes. Would the flood mechanism need to go into RPL or could it be put in a separate document? The right way to flood would seem to depend on the link layer and the network topology. > A real multicast operation in the intermediate nodes in pure source > route would require a new form of RH encoding, that's doable but not > necessarily trivial. Would we want that in the RH spec? I am not sure what you mean. I like the image of a mixed unicast/local flooding delivery mechanism. The root selectively sends out unicasts that burst into local floods when they reach their destination. Just like fireworks, except that we have our DAGs upside down. Sounds like a research topic, and thus out of scope. -Richard Kelsey From Jerald.P.Martocci@jci.com Wed May 19 10:21:45 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0503A6B24; Wed, 19 May 2010 10:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, 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 TIPpygvImSaZ; Wed, 19 May 2010 10:21:43 -0700 (PDT) Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by core3.amsl.com (Postfix) with ESMTP id 68F263A6B62; Wed, 19 May 2010 10:21:16 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKS/QeAWrahDCZeeBCBPn+FmldJuh0m/Kb@postini.com; Wed, 19 May 2010 10:21:10 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010051912212305-2215814 ; Wed, 19 May 2010 12:21:23 -0500 In-Reply-To: <028401caf6e5$c5592d60$500b8820$@com> References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> To: "Samita Chakrabarti" MIME-Version: 1.0 X-KeepSent: 89512AEF:6EFA43A6-86257728:005C7087; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 19 May 2010 12:20:54 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 05/19/2010 12:20:59 PM, Serialize complete at 05/19/2010 12:20:59 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/19/2010 12:21:23 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/19/2010 12:21:32 PM, Serialize complete at 05/19/2010 12:21:32 PM Content-Type: multipart/related; boundary="=_related 005F4C3E86257728_=" Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 17:21:45 -0000 This is a multipart message in MIME format. --=_related 005F4C3E86257728_= Content-Type: text/html; charset="US-ASCII"
Hi Samita,

With regards to multicast being a separate ID, it concerns me that if we proliferate IDs some may naturally atrophy or be discounted in time.  I believe that RPL should cover all the necessary IP functionality as applied to LLNs including multicast and P2P operations.  If a given implementation determines that for whatever reason the application does not need these features, then they need not be implemented.  However, I think the RFC should be holistic.

That being said, please note that I am a complete IETF neophyte.  Maybe there are ways to assure that separate ID stay in lock-step.  If this is true then I have no qualms about separate IDs.  If there is a chance that some IDs may fall into disrepair, then I opt for a single fully inclusive RPL ID.

With regards to multicast in building environments, currently there are two multicast use cases used in building control.  The first is for discovery purposes.  There is a need for a device to access data items from other devices.  The discovery and binding is done using a site multicast (or broadcast).  Often times the binding will be across two devices in the same LLN, however, it's very possible that the binding may cross subnets.  A case in point is the need to access the 'outdoor air temperature'.  This data is very important to the HVAC control algorithms.  However, buildings typically only deploy a single outdoor air temperature sensor across the entire enterprise.  Hence most references to the device will cross subnets.

The second use case will be for different building subsystems (e.g. Fire, Security, HVAC) to operate independently at the application layer, but to share the routing (meshing) capability to increase the density of the meshing nodes.

Regards,

Jerry





From: "Samita Chakrabarti" <samitac@ipinfusion.com>
To: "'Richard Kelsey'" <richard.kelsey@ember.com>, "'JP Vasseur'" <jpv@cisco.com>
Cc: roll@ietf.org
Date: 05/18/2010 06:56 PM
Subject: Re: [Roll] RPL Status





Hi Richard/JP,

> >
> > Here is a quick status. First, we would like to thank the WG again for
> > the continuous effort and lots of fruitful and productive work ! As
> > discussed in Anaheim, the plan is still to Last Call RPL before the
> > next IETF.
>
> We will have to do something about multicasts (ticket #30).
> The multicast text in the current draft has a number of limitiations; in
> particular, it requires that all nodes cache DAOs.
>
[SC>]  Ticket #30 is about clarification of text regarding the multicast
operation.
Indeed it is not clear and subject to implementor's interpretation.

> Forwarding multicasts using unicasts makes sense if relatively few nodes
> need to receive them.  For a multicast that needs to get to most or all of
a
> network, using unicasts seems likely to be both unreliable and
inefficient.
>

[SC>] BTW, is RPL also trying to solve multicast routing/forwarding
completely in all cases ? It might be better to have another id for the
detailed multicast forwarding/routing for all cases (multicast to all nodes
in LLN, multicast to nodes that are spread out under different parents far
from each other and trying communicate with each other etc.). It might be
easier for RPL draft to handle a set of common use cases with the existing
mechanism. I wonder what would be the typical applications today for RPL in
LLN ? Is it in the building network where most of the communication takes
place from one or two parent or grand-parent nodes to their descendants
using a multi-cast address?
That said, we also need to make sure the current multicast mechanism could
be extended to cover other scenarios.

Actually the current solution of using DAO to store the multicast address
and the corresponding members of the multicast address may work out. But I
agree it is more work on each parent node to aggregate the multicast
addresses, process them and store them and might also make a decision to
prune.

If we consider LLN to be a route-over only link, then modifying MLD
hop-limit and forwarding MLD messages are an option but we still need to
consider pruning.
A generic solution for multicast routing/forwarding in LLN seems to be a
non-trivial problem to be handled in RPL draft alone.

Thanks,
-Samita



_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--=_related 005F4C3E86257728_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_094BFEE4094BFCA4005F4C3E86257728> /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --=_related 005F4C3E86257728_=-- From gnawali@cs.stanford.edu Wed May 19 14:17:27 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5CF3A6895 for ; Wed, 19 May 2010 14:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.903 X-Spam-Level: X-Spam-Status: No, score=-2.903 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 RsoIBoOBKszx for ; Wed, 19 May 2010 14:17:26 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 61C793A687E for ; Wed, 19 May 2010 14:17:26 -0700 (PDT) Received: from mail-yw0-f201.google.com ([209.85.211.201]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1OEqdj-0000mW-0T for roll@ietf.org; Wed, 19 May 2010 14:17:19 -0700 Received: by ywh39 with SMTP id 39so2362953ywh.21 for ; Wed, 19 May 2010 14:17:18 -0700 (PDT) Received: by 10.150.14.12 with SMTP id 12mr497453ybn.282.1274303838143; Wed, 19 May 2010 14:17:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.7.7 with HTTP; Wed, 19 May 2010 14:16:58 -0700 (PDT) From: Omprakash Gnawali Date: Wed, 19 May 2010 14:16:58 -0700 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 764eb63bb4c91aa8ddbf2de6f9e489d2 Subject: [Roll] feedback on etxof X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 21:17:27 -0000 Thanks to the WG for the discussion and feedback on draft-gnawali-roll-etxof-00. Here is a link to the draft: http://tools.ietf.org/html/draft-gnawali-roll-etxof-00 We had discussions about the feasibility of computing bidirectional ETX when there are a large number of nodes. It turns out, it can be done. There was also the suggestion to convert some constants to parameters. I plan to describe MAX_ETX_LINK_CONST, MAX_ETX_PATH_CONST, and PARENT_SWITCH_ETX_THRESHOLD as parameters. One question - should we specify the default values of these parameters? Any other feedback on the draft? I would like to incorporate your suggestions when I update the draft. Thanks. - om_p From jpv@cisco.com Wed May 19 15:16:55 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB203A6ABC for ; Wed, 19 May 2010 15:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.424 X-Spam-Level: X-Spam-Status: No, score=-7.424 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_50=0.001, DATE_IN_PAST_12_24=0.992, 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 8NXIBFbFFHYN for ; Wed, 19 May 2010 15:16:54 -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 423163A6AA5 for ; Wed, 19 May 2010 15:16: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: Am4DAML/80uQ/uCWe2dsb2JhbAAwnU4VAQEWIgYcpHqZUoJagjYEjzw X-IronPort-AV: E=Sophos;i="4.53,265,1272844800"; d="scan'208";a="61606066" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 May 2010 22:16:32 +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 o4JMGW17016169; Wed, 19 May 2010 22:16:32 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 00:16:32 +0200 Received: from [10.109.83.175] ([10.61.98.156]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 00:16:31 +0200 Message-Id: <9101C1BD-D42B-427E-881E-92F77806BA60@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <352039149.12399081274204469006.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 May 2010 05:35:54 +0200 References: <352039149.12399081274204469006.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 May 2010 22:16:31.0809 (UTC) FILETIME=[EF7A7B10:01CAF7A0] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17394.002 X-TM-AS-Result: No--25.670800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: Emmanuel Baccelli , roll Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 22:16:55 -0000 Hi, On May 18, 2010, at 7:41 PM, Mukul Goyal wrote: > Philip > >>> Note that we chose not to go deep into metrics/"routing cost" >>> discussion in the p2p draft, simply because different people have >>> very strong and very different opinions on what is right and what >>> is wrong. > >> I'm sorry; I need to argue this point. This isn't a question of >> opinion. It's a question of overwhelming scientific evidence and >> deployment experiences from real networks. Here are two simple >> published studies[1,2]. > > You are ignoring the fact that there are scenarios (especially, in > home automation environment; Anders may back me up on this), where a > device can not maintain any neighbor-specific state (e.g. the cost > of the link to the neighbor or even the identity of the neighbor). > You can not argue that hop-count should not be used even in such > situations. It may be a bad metric in general but it may still be > the only metric that can be used in a given situation. > I agree that the mechanism should stay "agnostic" to the metric in use and should support different kind of metrics similarly to RPL (base spec) in general. >>> A node should not forward a Discovery message further if it does >>> not have the relevant link-level cost estimates. > >> I think that is this is changed to MUST NOT, then it could be OK. >> Or how about > > "A node MUST NOT forward a Discovery message from a node for which > it does not have relevant link-level metric information." > > I am OK with changing "should not" to "MUST NOT". There is a problem > with the text you suggested. Suppose a _forward_ route is being > discovered as per a certain routing metric. Node B receives a > discovery message from node A. As per your text, node B must not > forward the message further if cost B->A is unavailable/bad. But, > cost B->A is irrelevant in this case. Your text assumes that routing > metrics are symmetrical enough to conclude that link A->B must be > bad if link B->A is bad. Whether this assumption is valid or not > depends on the definition of the routing metric/cost and is not some > thing that should concern the route discovery protocol. The route > discovery protocol needs to be agnostic about the metrics being used. Agree. > Would you be OK with the text I suggested with "MUST NOT" replacing > "should not": > Yes, just add a short justification. > A node MUST NOT forward a Discovery message further if it does not > have the relevant link-level cost estimates. > >>> Note that we can not really refer to the "neighbor table" as you >>> had suggested earlier. > >> Why? > > Because, a neighbor table may not exist since nodes are too > constrained to maintain per-neighbor states. > > Thanks > Mukul > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Wed May 19 15:16:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A63B03A6AE3 for ; Wed, 19 May 2010 15:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.714 X-Spam-Level: X-Spam-Status: No, score=-8.714 tagged_above=-999 required=5 tests=[AWL=0.893, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 EWTCZV8PbRVM for ; Wed, 19 May 2010 15:16:55 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4510B3A6AB2 for ; Wed, 19 May 2010 15:16:41 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMGAEUA9EurR7Ht/2dsb2JhbAAwnU5xpH2ZUoUQBA X-IronPort-AV: E=Sophos;i="4.53,265,1272844800"; d="scan'208";a="223230328" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 19 May 2010 22:16:34 +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 o4JMGXw8011672; Wed, 19 May 2010 22:16:34 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 00:16:32 +0200 Received: from [10.109.83.175] ([10.61.98.156]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 00:16:32 +0200 Message-Id: <8DB135A8-0571-43C2-9D71-57B1201AC678@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <87ljbhytat.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 May 2010 05:40:23 +0200 References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D01E861A6@XMB-AMS-107.cisco.com> <87ljbhytat.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 May 2010 22:16:32.0621 (UTC) FILETIME=[EFF661D0:01CAF7A0] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17394.002 X-TM-AS-Result: No--27.375200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] RPL multicast (was Re: RPL Status) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 22:16:57 -0000 On May 18, 2010, at 8:10 PM, Richard Kelsey wrote: >> Date: Tue, 18 May 2010 18:12:59 +0200 >> From: "Pascal Thubert (pthubert)" >> >>> Richard Kelsey >>> Sent: Tuesday, May 18, 2010 4:47 PM >>> >>> We will have to do something about multicasts (ticket #30). >>> The multicast text in the current draft has a number of >>> limitiations; >>> in particular, it requires that all nodes cache DAOs. >>> >>> Forwarding multicasts using unicasts makes sense if relatively few >>> nodesneed to receive them. For a multicast that needs to get to >>> most or all of a network, using unicasts seems likely to be both >>> unreliable and inefficient. > >> Good point. Would you have a suggestion for the source route world? > > Pascal, > > It's a hard problem. > > ZigBee, which has always-on routers, uses hop-limited > flooding for multicasts. This works well for multicasts > that need to go to all or almost all nodes. > > I do not know how multicasts are handled in sensor networks, > where flooding is relatively expensive. > > In the source route world, for multicasts with few > subscribers, the simplest thing would to use DAOs > more-or-less as is done for downward routes. MLD requests > would be forwarded up to the root, and the root would keep > track of which nodes were subscribed to which multicast > addresses. Multicasts would be also forwarded to the root, > which would unicast them down to subscribers. I suppose the > root could also make the determination as to which > multicasts could be more effectively flooded. Correct. > > More complicated schemes are possible, but I don't like more > complicated schemes :-). Since you asked ;-) Such schemes have been developed for other protocols such as MPLS, for example in the case of P2MP Traffic Engineering Label Switched Path (TE LSP) where the path is computed by the head (for some PCE) and where the computed paths is provided by the signaling protocol (RSVP-TE) when setting up the TE LSP. There are many ways to encode the P2MP TE LSP path so one could adopt a similar approach using a new RH but that means non-negligible overheard to say the least in the data path ... Note that new P2MP forwarding schemes are not within the scope of ROLL, which provides a P2MP/Multicast routing solution only. Thanks. JP. > -Richard Kelsey > From jpv@cisco.com Wed May 19 15:17:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DAF63A6AEB for ; Wed, 19 May 2010 15:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.806 X-Spam-Level: X-Spam-Status: No, score=-7.806 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_20=-0.74, DATE_IN_PAST_12_24=0.992, 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 RPEmx0mX+YPB for ; Wed, 19 May 2010 15:16:59 -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 3B9EE3A6ABA for ; Wed, 19 May 2010 15:16:42 -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: AgMGAEUA9EurR7Ht/2dsb2JhbAAwnU5xpH2ZUoUQBI88 X-IronPort-AV: E=Sophos;i="4.53,265,1272844800"; d="scan'208";a="532380402" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 19 May 2010 22:16:35 +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 o4JMGXwA011672; Wed, 19 May 2010 22:16:35 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 00:16:33 +0200 Received: from [10.109.83.175] ([10.61.98.156]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 00:16:33 +0200 Message-Id: <50547F37-DFA1-46E7-B8DC-146A1044461B@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <52410827.12575211274219649358.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 May 2010 05:44:46 +0200 References: <52410827.12575211274219649358.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 May 2010 22:16:33.0512 (UTC) FILETIME=[F07E5680:01CAF7A0] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17394.002 X-TM-AS-Result: No--27.463900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: Emmanuel Baccelli , roll WG Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 22:17:00 -0000 Hi Mukul, Few comments in line. On May 18, 2010, at 11:54 PM, Mukul Goyal wrote: > Hi Philip, JP > > Here is a list of the controls that can be used to limit the spread > of discovery messages: > > 1. If a node does not know the link cost, it wont forward the > discovery message further (was implicit in the p2p draft; now would > be made explicit); > 2. If a node receives a discovery message advertizing a rank (in the > temporary DAG) higher than the node's current rank, the discovery > message is ignored; > 3. If the discovery message has already traveled a certain > "distance" (determined based on the rank that the receiving node > would achieve in the temporary DAG using the rank advertized in the > discovery message), it wont be forwarded any further; > 4. If the end-to-end cost for the path taken by the discovery > message so far already fails the "good enough" criteria, the > discovery message is not forwarded any further; (this control is > optional since the "good enough" criteria may be too difficult for a > constrained intermediate node to calculate) Note that there are quite a few vague/hard to define parameters: "Certain" distance, "good enough" that will require more detailed explanations. > 5. The trickle timer. > See my previous message .... you may because of that ignore a "better" path, the whole reason for using this P2P scheme. > The trickle timer helps control the spread of discovery messages in > following ways: > 1. The timer's interval can be chosen to "speed up" the discovery > message or "slow it" down; the tradeoff being the number of > discovery messages generated. A large interval allows only one > message to be sent in response to several received. > 2. The redundancy threshold of the trickle timer can optionally be > used to further limit the generation of discovery messages. Do not > generate your own discovery message if you have already received "n" > messages advertizing the same/better rank or e2e cost than what you > will advertize. > Not a showstopper by all means but still lots of knobs difficult to define ... > I guess a node could also employ a local policy regarding when and > how many times to generate a discovery message: > 1. generate discovery messages only a certain number of times; > 2. do not generate a discovery message at the timer's firing if the > rank/cost to be advertized is same as before; > 2. always generate a discovery message at the timer's firing > (irrespective of the redundancy threshold) if the new cost/rank to > be advertized is better than before. > > So, to answer your question: > > "are you suggesting using Trickle as the route discovery mechanism, > or as the data delivery mechanism? " > > I would say that we are using trickle as an additional control over > the generation of discovery messages. > Which should be the case. Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "Philip Levis" > To: "JP Vasseur" > Cc: "Mukul Goyal" , "Anders Brandt" > , "roll WG" , "Emmanuel Baccelli" > > Sent: Tuesday, May 18, 2010 10:36:46 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll- > p2p-rpl-00 > > > > > On May 18, 2010, at 2:24 AM, JP Vasseur wrote: > > > > > > > [Anders] I understand your concern and if you have resources > > > in a node for doing more intelligent forwarding decisions, this > > > is wonderful. > > > For the most constrained nodes, however, I love the simplicity > > > of Trickle where you forward (randomized schedule) as long as > > > you have picked up less than n copies of the discovery message > > > from you direct range neighbors. > > But that requires to be cautious too since that could eliminate some > "good" paths too, and > in particular the ones that are better than the DODAG path. > > > Anders -- are you suggesting using Trickle as the route discovery > mechanism, or as the data delivery mechanism? > > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Wed May 19 15:17:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C363A6ADD for ; Wed, 19 May 2010 15:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=-4.263, BAYES_40=-0.185, DATE_IN_PAST_12_24=0.992, 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 dwWP1Uxv0g+i for ; Wed, 19 May 2010 15:17:26 -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 EA3C53A6AD3 for ; Wed, 19 May 2010 15:16:52 -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: ApADAEUA9EuQ/uCWe2dsb2JhbAAwgQ+cPxUBARYiBhykfZlShRAE X-IronPort-AV: E=Sophos;i="4.53,265,1272844800"; d="scan'208,217";a="7637216" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 19 May 2010 21:38:12 +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 o4JMGiTZ016216; Wed, 19 May 2010 22:16:44 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 00:16:44 +0200 Received: from [10.109.83.175] ([10.61.98.156]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 00:16:44 +0200 Message-Id: From: JP Vasseur To: "Anders Brandt" In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A162@zensys17.zensys.local> Content-Type: multipart/alternative; boundary=Apple-Mail-85--418226128 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 May 2010 06:01:57 +0200 References: <924380927.4075181272476786921.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E0142A150@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E0142A162@zensys17.zensys.local> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 May 2010 22:16:44.0184 (UTC) FILETIME=[F6DAC180:01CAF7A0] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17394.002 X-TM-AS-Result: No--27.285200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll , Mukul Goyal Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 22:17:28 -0000 --Apple-Mail-85--418226128 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Anders, On May 17, 2010, at 4:18 PM, Anders Brandt wrote: > Hi JP > > Please find comments inline > > - Anders > > > From: JP Vasseur [mailto:jpv@cisco.com] > Sent: Monday, May 17, 2010 15:05 > To: Anders Brandt; Mukul Goyal > Cc: roll > Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll- > p2p-rpl-00 > > Hi Anders, > > Co-chair hat-off. > > I think that it goes in right direction. > > Few comments for the moment. > > 1) o The constraint to route only along a DAG leading to > significantly > suboptimal P2P routes and traffic congestion near the DAG root. > JP> You may want to soften the statement here since the path > computed along the DAG > may be sub-optimal .. it all depends on the destination, degree of > meshing of the DAG, etc ... > I think that the argument of not having to maintain route > maintenance for some nodes is > more compelling. > > > What about: > "The constraint to route only along a DAG potentially leading to > significantly > suboptimal P2P routes and traffic congestion near the DAG root." ? OK > 2) Such applications require a mechanism for "reactive route > discovery" > and the ability to route "across DAGs". > > JP> Why is it required to route across DAGs ? I guess that you meant > "non DAG" routes ? > > Agreed. What the text should say is: > "across a DAG", "across the branches of a dag" or "along non-DAG > routes" (pick one) I would choose "non DAG route" > 3) The mechanisms described in this document are intended to be > employed > as complementary to RPL in specific scenarios that need point-to- > point (P2P) routes between arbitrary nodes. > > JP> More specifically, I think that we agree that it will be part of > RPL, as an optional mechanism. > > Negative. > RPL will never be able to deliver the required performance for home > and > building without decent support for battery operation and reactive > self-healing. You misunderstood my point. The WG agreed that this was a MUST, I am not questioning the usefulness of it. I just meant to say that all implementations will not need it, that's all (thus the term optional). > > 4) Section 4.2: objective function > > JP> You actually do not need an OF for that. Just use the metrics > specified in the Routing-metrics ID, > adding a path-cost-bound object (for the "good enough" criteria). > > Great. This is an example of why it will be valuable for RPL as a > whole if the WG starts discussing > how to achieve the stated goals of the draft. > OF or metrics - I leave it for the experts to decide which is the > right thing. As long as I can ask for a > "good enough" route as result of a reactive discovery. I need the > lamp to turn on with low delay. > Later, I may have time for fine-tuning the route. We're in sync. > > > 5) 4.6. Transport of Routing Metrics > The Metric Container option defined in RPL-07 can be used to carry > both the aggregated end-to-end and the local values for the routing > metrics being used to define the routing cost. Additional metric > objects may need to be defined to carry the aggregated end-to-end > routing cost and a source-route unmodified from one node to > another; > > JP> with regards to the second part of the paragraph I would suggest > to use the same metrics as defined > in the routing-metric ID. > > 6) We just need to have a section somewhere indicating that such > reactive mechanism has a cost too and the resulting > path cost decrease is not known a priori and may end up being close > to the DAG cost for that destination. I am not > questioning the usefulness of the mechanism, just make sure to > indicate it. > I can help provide some text, if that helps. Thanks. JP. > Thanks. > > JP. > > On May 17, 2010, at 9:28 AM, Anders Brandt wrote: > >> Hi all >> >> The P2P draft has been out for some weeks now. >> The team would like to poll the WG for directions whether this is >> the right approach. >> >> >> >> Phil has indicated some agreement. >> What about the rest of the WG? >> >> Others in favour of the work? >> Any alternative proposals? >> >> Otherwise the P2P team will conclude that we are on the right track >> and go on proposing specific frame format additions/modifications >> and mechanisms for RPL. >> When the required maturity is reached, those proposed additions/ >> changes >> should be adopted by the RPL spec; thus obsoleting this draft. >> >> Thanks, >> Anders >> >> >>> On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote: >>> >>>> Hi all >>>> >>>> The following draft has been submitted for WG's consideration. It >>>> describes the additional mechanisms required to support P2P >>> routing in >>>> LLNs. The draft first provides a high level description of the >>>> mechanisms and then proposes one way of realizing these >>> mechanisms in >>>> RPL. >>>> >>>> Regards >>>> Mukul >>>> >>>> ----- Forwarded Message ----- >>>> From: "IETF I-D Submission Tool" >>>> To: mukul@uwm.edu >>>> Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada >>>> Central >>>> Subject: New Version Notification for draft-dt-roll-p2p-rpl-00 >>>> >>>> >>>> A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been >>>> successfully submitted by Mukul Goyal and posted to the IETF >>>> repository. >>>> >>>> Filename: draft-dt-roll-p2p-rpl >>>> Revision: 00 >>>> Title: Mechanisms to Support Point-to-Point >>> Routing in Low Power >>>> and Lossy Networks >>>> Creation_date: 2010-04-28 >>>> WG ID: Independent Submission >>>> Number_of_pages: 13 >>>> >>>> Abstract: >>>> This draft presents mechanisms to determine the end-to-end >>> cost of an >>>> existing route and to discover/establish "on demand" one or more >>>> routes between two nodes in a low power and lossy network. >>> This draft >>>> also proposes functionality that would enable RPL to >>> provide these P2P >>>> mechanisms. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> _______________________________________________ >>>> 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 > > --Apple-Mail-85--418226128 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Anders,

On = May 17, 2010, at 4:18 PM, Anders Brandt wrote:

Hi JP
 
=
Please find comments = inline
=
 
- = Anders
 

=
From: JP = Vasseur [mailto:jpv@cisco.com] =
Sent: Monday, May 17, 2010 15:05
To: Anders Brandt; = Mukul Goyal
Cc: roll
Subject: Re: [Roll] Fwd: New = Version Notification fordraft-dt-roll-p2p-rpl-00

=
Hi Anders,

Co-chair hat-off.

I = think that it goes in right direction.

Few comments for = the moment.

1)  o The = constraint to route only along a DAG leading to = significantly
   =
   suboptimal P2P routes and traffic congestion near the DAG root.
JP> You may want to soften the statement here since the = path computed along the DAG 
may be sub-optimal .. it = all depends on the destination, degree of meshing of the DAG, etc = ...
I think that the argument of not having to maintain = route maintenance for some nodes is 
more compelling. 
 

What = about:
"The constraint to route only along a DAG = potentially leading to significantly
suboptimal P2P = routes and traffic congestion near the DAG root."   = ?

OK
2)  Such applications require a = mechanism for "reactive route discovery"
   and the ability to route "across =
DAGs".

JP> Why is it required to route = across DAGs ? I guess that you meant "non DAG" routes ? 
 
Agreed. What the text should = say is:
"across a DAG", "across the = branches of a dag" or "along non-DAG routes"  (pick = one) 

I would choose "non DAG route"
3) The mechanisms described in this = document are intended to be employed
   as complementary to RPL in specific =
scenarios that need point-to-
   point (P2P) routes between arbitrary nodes.

=
JP> More = specifically, I think that we agree that it will be part of RPL, as an = optional mechanism. 
 
=
Negative. =
=
RPL will never be able to deliver the = required performance for home and
building without decent support for battery operation and = reactive = self-healing.
<= /div>

You misunderstood my point. The WG = agreed that this was a MUST, I am not questioning the = usefulness
of it. I just meant to say that all implementations = will not need it, that's all (thus the term = optional).

=

4) Section 4.2: objective function
=

=
JP> You = actually do not need an OF for that. Just use the metrics specified in = the Routing-metrics ID,
adding a path-cost-bound = object (for the "good enough" criteria). 
 
=
=
=
=
Great. This is an example of why it will be = valuable for RPL as a whole if the WG starts = discussing
how to achieve the stated goals of the = draft.
OF or metrics - I leave it = for the experts to decide which is the right thing. As long as I can ask = for a
"good enough" route as = result of a reactive discovery. I need the lamp to turn on with low = delay.
Later, I may have time for = fine-tuning the = route.

We're in = sync.

 
5) 4.6. = Transport of Routing Metrics
   The Metric Container option defined in RPL-07 can be =
used to carry
   both the aggregated end-to-end and the local values for the routing
   metrics being used to define the routing cost.  Additional metric
   objects may need to be defined to carry the aggregated end-to-end
   routing cost and a source-route unmodified from one node to =
another;

JP> with regards to the = second part of the paragraph I would suggest to use the same metrics = as defined
in the routing-metric ID.

=
6) We just need = to have a section somewhere indicating that such reactive mechanism = has a cost too and the resulting
path cost decrease is not = known a priori and may end up being close to the DAG cost for that = destination. I am not
questioning the usefulness of the mechanism, just = make sure to indicate it.

I= can help provide some text, if that = helps.

Thanks.

JP.
=
Thanks.

=
JP.
=

On May 17, = 2010, at 9:28 AM, Anders Brandt wrote:

=
Hi all

The P2P draft has been out for some weeks now.
The = team would like to poll the WG for directions whether this is
the = right approach.



Phil has indicated some = agreement.
What about the rest of the WG?

Others in favour = of the work?
Any alternative proposals?

Otherwise the P2P = team will conclude that we are on the right track
and go on = proposing specific frame format additions/modifications
and = mechanisms for RPL.
When the required maturity is reached, those = proposed additions/changes
should be adopted by the RPL spec; = thus obsoleting this = draft.

Thanks,
 Anders


On Apr 28, 2010, at 7:46 PM, Mukul Goyal = wrote:

=
Hi = all
=

The following draft has = been submitted for WG's consideration. It =
=
describes the additional mechanisms required = to support P2P
routing in
=
LLNs. The draft first provides a high = level description of the
=
mechanisms and = then proposes one way of realizing these =
mechanisms = in
RPL.

=
Regards
=
Mukul

=
----- Forwarded Message = -----
=
From: "IETF I-D Submission Tool" <idsubmission@ietf.org>
To: mukul@uwm.edu
Sent: = Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada =
=
Central
=
Subject: New = Version Notification for = draft-dt-roll-p2p-rpl-00

=

=
A new version = of I-D, draft-dt-roll-p2p-rpl-00.txt has been =
=
successfully submitted by Mukul Goyal and = posted to the IETF
repository.

=
Filename: = draft-dt-roll-p2p-rpl
=
Revision: = 00
=
Title: Mechanisms to Support Point-to-Point =
Routing = in Low Power  
=
and Lossy = Networks
=
Creation_date: = 2010-04-28
WG ID: Independent = Submission
=
Number_of_pages: = 13
=

Abstract:
This draft presents = mechanisms to determine the end-to-end =
cost of an =
existing route and to discover/establish "on = demand" one or more
routes between two nodes = in a low power and lossy network. =  
This = draft
also proposes functionality that would enable RPL = to
provide = these P2P
=
mechanisms.
=

=

=

=
The IETF = Secretariat.
=

=

=
_______________________________________________
Roll mailing list
=
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_______________________________________________
Roll mailing list
=
Roll@ietf.org
=
https://www.ietf.org/m= ailman/listinfo/roll

___________________________________________= ____
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
=


= --Apple-Mail-85--418226128-- From prvs=749dee93c=mukul@uwm.edu Wed May 19 17:56:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FD128C0DE for ; Wed, 19 May 2010 17:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 n7KAhLkc5Gin for ; Wed, 19 May 2010 17:56:08 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id B665E3A6AD8 for ; Wed, 19 May 2010 17:56:08 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 19 May 2010 19:56:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 860682C38010; Wed, 19 May 2010 19:56:01 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd2o2L7WVxVN; Wed, 19 May 2010 19:56:01 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 11B7B2C3800D; Wed, 19 May 2010 19:56:01 -0500 (CDT) Date: Wed, 19 May 2010 19:56:01 -0500 (CDT) From: Mukul Goyal To: JP Vasseur Message-ID: <926259539.13118641274316960978.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2072221509.13116741274316562733.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 00:56:10 -0000 Hi JP >6) We just need to have a section somewhere indicating that such reactive = mechanism has a cost too and the resulting path cost decrease is not known a priori and may end up being close to the = DAG cost for that destination. I am not questioning the usefulness of the mechanism, just make sure to indicate it. >I can help provide some text, if that helps. Sure, please send me the text you would like to see in the draft. Also, I w= anted to point out that the purpose of the measurement messages is to help = decide whether to initiate a reactive route discovery ot not. If the measur= ement of the cost of an existing (DAG-based) route indicates that this rout= e is good enough, there wont be a need to do a reactive discovery. Further,= the "good enough" criteria can be selected on the basis of information pro= vided by measurement messages. If the measurement on a DAG-based route retu= rns an end-to-end cost "x", the good enough criteria can be set to some fra= ction of x thereby ensuring that any discovered P2P routes have a certain m= inimum cost advantage over DAG-based route. Ofcourse, there may not exist a= ny P2P routes with such advantage (and that's why we need to put in the tex= t that you are suggesting). Thanks Mukul =20 ----- Original Message ----- From: "JP Vasseur" To: "Anders Brandt" Cc: "Mukul Goyal" , "roll" Sent: Tuesday, May 18, 2010 11:01:57 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-= 00 Hi Anders,=20 On May 17, 2010, at 4:18 PM, Anders Brandt wrote:=20 Hi JP=20 =C2=A0=20 Please find comments inline=20 =C2=A0=20 - Anders=20 =C2=A0=20 From: JP Vasseur [ mailto:jpv@cisco.com ]=20 Sent: Monday, May 17, 2010 15:05=20 To: Anders Brandt; Mukul Goyal=20 Cc: roll=20 Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-= 00=20 Hi Anders,=20 Co-chair hat-off.=20 I think that it goes in right direction.=20 Few comments for the moment.=20 1)=C2=A0 o The constraint to route only along a DAG leading to significantl= y suboptimal P2P routes and traffic congestion near the DAG root.=20 JP> You may want to soften the statement here since the path computed along= the DAG=C2=A0=20 may be sub-optimal .. it all depends on the destination, degree of meshing = of the DAG, etc ...=20 I think that the argument of not having to maintain route maintenance for s= ome nodes is=C2=A0=20 more compelling. =C2=A0=20 =C2=A0=20 What about:=20 "The constraint to route only along a DAG potentially leading to significan= tly=20 suboptimal P2P routes and traffic congestion near the DAG root."=C2=A0=C2= =A0 ?=20 OK=20 2)=C2=A0 Such applications require a mechanism for "reactive route discover= y" and the ability to route "across DAGs".=20 JP> Why is it required to route across DAGs ? I guess that you meant "non D= AG" routes ? =C2=A0=20 =C2=A0=20 Agreed. What the text should say is:=20 "across a DAG", "across the branches of a dag" or "along non-DAG routes"=C2= =A0 (pick one) =C2=A0=20 I would choose "non DAG route"=20 3)=C2=A0 The mechanisms described in this document are intended to be emplo= yed as complementary to RPL in specific scenarios that need point-to- point (P2P) routes between arbitrary nodes.=20 JP> More specifically, I think that we agree that it will be part of RPL, a= s an optional mechanism. =C2=A0=20 =C2=A0=20 Negative.=20 RPL will never be able to deliver the required performance for home and=20 building without decent support for battery operation and reactive self-hea= ling.=20 You misunderstood my point. The WG agreed that this was a MUST, I am not qu= estioning the usefulness=20 of it. I just meant to say that all implementations will not need it, that'= s all (thus the term optional).=20 4) Section 4.2: objective function=20 JP> You actually do not need an OF for that. Just use the metrics specified= in the Routing-metrics ID,=20 adding a path-cost-bound object (for the "good enough" criteria). =C2=A0=20 =C2=A0=20 Great. This is an example of why it will be valuable for RPL as a whole if = the WG starts discussing=20 how to achieve the stated goals of the draft.=20 OF or metrics - I leave it for the experts to decide which is the right thi= ng. As long as I can ask for a=20 "good enough" route as result of a reactive discovery. I need the lamp to t= urn on with low delay.=20 Later, I may have time for fine-tuning the route.=20 We're in sync.=20 =C2=A0=20 5)=C2=A0 4.6. Transport of Routing Metrics The Metric Container option defi= ned in RPL-07 can be used to carry both the aggregated end-to-end and the local values for the routing metrics being used to define the routing cost. Additional metric objects may need to be defined to carry the aggregated end-to-end routing cost and a source-route unmodified from one node to another;=20 JP> with regards to the second part of the paragraph I would suggest to use= the same metrics as defined=20 in the routing-metric ID.=20 6) We just need to have a section somewhere indicating that such reactive m= echanism has a cost too and the resulting=20 path cost decrease is not known a priori and may end up being close to the = DAG cost for that destination. I am not=20 questioning the usefulness of the mechanism, just make sure to indicate it.= =20 I can help provide some text, if that helps.=20 Thanks.=20 JP.=20 Thanks.=20 JP.=20 On May 17, 2010, at 9:28 AM, Anders Brandt wrote:=20 Hi all=20 The P2P draft has been out for some weeks now.=20 The team would like to poll the WG for directions whether this is=20 the right approach.=20 Phil has indicated some agreement.=20 What about the rest of the WG?=20 Others in favour of the work?=20 Any alternative proposals?=20 Otherwise the P2P team will conclude that we are on the right track=20 and go on proposing specific frame format additions/modifications=20 and mechanisms for RPL.=20 When the required maturity is reached, those proposed additions/changes=20 should be adopted by the RPL spec; thus obsoleting this draft.=20 Thanks,=20 =C2=A0Anders=20 On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote:=20 Hi all=20 The following draft has been submitted for WG's consideration. It=20 describes the additional mechanisms required to support P2P=20 routing in=20 LLNs. The draft first provides a high level description of the=20 mechanisms and then proposes one way of realizing these=20 mechanisms in=20 RPL.=20 Regards=20 Mukul=20 ----- Forwarded Message -----=20 From: "IETF I-D Submission Tool" < idsubmission@ietf.org >=20 To: mukul@uwm.edu=20 Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada=20 Central=20 Subject: New Version Notification for draft-dt-roll-p2p-rpl-00=20 A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been=20 successfully submitted by Mukul Goyal and posted to the IETF=20 repository.=20 Filename: draft-dt-roll-p2p-rpl=20 Revision: 00=20 Title: Mechanisms to Support Point-to-Point=20 Routing in Low Power =C2=A0=20 and Lossy Networks=20 Creation_date: 2010-04-28=20 WG ID: Independent Submission=20 Number_of_pages: 13=20 Abstract:=20 This draft presents mechanisms to determine the end-to-end=20 cost of an=20 existing route and to discover/establish "on demand" one or more=20 routes between two nodes in a low power and lossy network. =C2=A0=20 This draft=20 also proposes functionality that would enable RPL to=20 provide these P2P=20 mechanisms.=20 The IETF Secretariat.=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 From prvs=749dee93c=mukul@uwm.edu Wed May 19 18:05:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6AC3A68D6 for ; Wed, 19 May 2010 18:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=1.255, 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 HpjFvgFSHjAy for ; Wed, 19 May 2010 18:05:21 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 53CAC3A689B for ; Wed, 19 May 2010 18:05:21 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 19 May 2010 20:05:12 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 6AA4F2C3800E; Wed, 19 May 2010 20:05:12 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCSthM2vAtgb; Wed, 19 May 2010 20:05:12 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 406F22C38010; Wed, 19 May 2010 20:05:12 -0500 (CDT) Date: Wed, 19 May 2010 20:05:12 -0500 (CDT) From: Mukul Goyal To: JP Vasseur Message-ID: <1387149801.13120851274317512178.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <9101C1BD-D42B-427E-881E-92F77806BA60@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: Emmanuel Baccelli , roll Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 01:05:22 -0000 Hi JP, >>> A node should not forward a Discovery message further if it does >>> not have the relevant link-level cost estimates. > [Philip] >> I think that is this is changed to MUST NOT, then it could be OK. >> Or how about > > "A node MUST NOT forward a Discovery message from a node for which > it does not have relevant link-level metric information." > [Mukul] > I am OK with changing "should not" to "MUST NOT". There is a problem > with the text you suggested. Suppose a _forward_ route is being > discovered as per a certain routing metric. Node B receives a > discovery message from node A. As per your text, node B must not > forward the message further if cost B->A is unavailable/bad. But, > cost B->A is irrelevant in this case. Your text assumes that routing > metrics are symmetrical enough to conclude that link A->B must be > bad if link B->A is bad. Whether this assumption is valid or not > depends on the definition of the routing metric/cost and is not some > thing that should concern the route discovery protocol. The route > discovery protocol needs to be agnostic about the metrics being used. > Would you be OK with the text I suggested with "MUST NOT" replacing > "should not": > [JP] Yes, just add a short justification. [Mukul] Will do. Thanks Mukul > A node MUST NOT forward a Discovery message further if it does not > have the relevant link-level cost estimates. > From prvs=749dee93c=mukul@uwm.edu Wed May 19 18:39:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C603A6858 for ; Wed, 19 May 2010 18:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[AWL=-0.119, 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 kn0oQ1zBemeu for ; Wed, 19 May 2010 18:39:24 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 24EFF3A6881 for ; Wed, 19 May 2010 18:39:24 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 19 May 2010 20:39:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 191282C3800E; Wed, 19 May 2010 20:39:17 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSCqwRwV1PwP; Wed, 19 May 2010 20:39:04 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id D1F9B2C3800D; Wed, 19 May 2010 20:39:04 -0500 (CDT) Date: Wed, 19 May 2010 20:39:04 -0500 (CDT) From: Mukul Goyal To: JP Vasseur Message-ID: <268872740.13130131274319544778.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <946564699.13128091274319000086.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: Emmanuel Baccelli , roll WG Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 01:39:25 -0000 Hi JP [Mukul] > Here is a list of the controls that can be used to limit the spread > of discovery messages: > > 1. If a node does not know the link cost, it wont forward the > discovery message further (was implicit in the p2p draft; now would > be made explicit); > 2. If a node receives a discovery message advertizing a rank (in the > temporary DAG) higher than the node's current rank, the discovery > message is ignored; > 3. If the discovery message has already traveled a certain > "distance" (determined based on the rank that the receiving node > would achieve in the temporary DAG using the rank advertized in the > discovery message), it wont be forwarded any further; > 4. If the end-to-end cost for the path taken by the discovery > message so far already fails the "good enough" criteria, the > discovery message is not forwarded any further; (this control is > optional since the "good enough" criteria may be too difficult for a > constrained intermediate node to calculate) [JP] Note that there are quite a few vague/hard to define parameters: "Certain" distance, "good enough" that will require more detailed explanations. [Mukul] The "distance" that the discovery messages may travel would be represented by a maximum limit on the rank in the temporary DAG. This maximum limit on rank I suppose is a configuration parameter. The "good enough" criteria may be tied up to the e2e cost of any existing DAG-based route or it could be a configuration parameter as well. Do you think that these two concepts are not well described in the draft? [JP] > 5. The trickle timer. > See my previous message .... you may because of that ignore a "better" path, the whole reason for using this P2P scheme. [Mukul] Not sure how. A node would always generate a discovery message at the (periodic) expiry of the trickle timer if it has a better cost to advertize (unless the local policy some how prevents it from doing so). [JP] > The trickle timer helps control the spread of discovery messages in > following ways: > 1. The timer's interval can be chosen to "speed up" the discovery > message or "slow it" down; the tradeoff being the number of > discovery messages generated. A large interval allows only one > message to be sent in response to several received. > 2. The redundancy threshold of the trickle timer can optionally be > used to further limit the generation of discovery messages. Do not > generate your own discovery message if you have already received "n" > messages advertizing the same/better rank or e2e cost than what you > will advertize. > Not a showstopper by all means but still lots of knobs difficult to define ... [Mukul] But these knobs are standard/integral part of a trickle timer. Thanks Mukul From yoav@yitran.com Wed May 19 23:06:46 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFC263A6966 for ; Wed, 19 May 2010 23:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.275 X-Spam-Level: X-Spam-Status: No, score=-4.275 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 V+1dgTpu87sK for ; Wed, 19 May 2010 23:06:45 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id B561D3A6CE3 for ; Wed, 19 May 2010 23:05:36 -0700 (PDT) Received: from source ([209.85.160.50]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKS/TRKYvbx1jxBtFlZBrVjvfKnus+YS+s@postini.com; Wed, 19 May 2010 23:05:30 PDT Received: by pwj7 with SMTP id 7so197995pwj.23 for ; Wed, 19 May 2010 23:05:29 -0700 (PDT) Received: by 10.115.39.39 with SMTP id r39mr8338631waj.157.1274335529200; Wed, 19 May 2010 23:05:29 -0700 (PDT) From: Yoav Ben-Yehezkel References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr3mK4CYEGhRCBqTKehjr5bfCd2lgASPYzg Date: Thu, 20 May 2010 09:05:25 +0300 Message-ID: <5ad2db1750f025e127db4d7e285a3f39@mail.gmail.com> To: Omprakash Gnawali Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: Re: [Roll] feedback on etxof X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 06:06:46 -0000 Small typo - "draft-gnawali-roll-etxof-00" should appear in the header instead of: "Abbreviated Title" Regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Omprakash Gnawali Sent: Thursday, May 20, 2010 12:17 AM To: ROLL WG Subject: [Roll] feedback on etxof Thanks to the WG for the discussion and feedback on draft-gnawali-roll-etxof-00. Here is a link to the draft: http://tools.ietf.org/html/draft-gnawali-roll-etxof-00 We had discussions about the feasibility of computing bidirectional ETX when there are a large number of nodes. It turns out, it can be done. There was also the suggestion to convert some constants to parameters. I plan to describe MAX_ETX_LINK_CONST, MAX_ETX_PATH_CONST, and PARENT_SWITCH_ETX_THRESHOLD as parameters. One question - should we specify the default values of these parameters? Any other feedback on the draft? I would like to incorporate your suggestions when I update the draft. Thanks. - om_p _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Thu May 20 05:40:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314DE3A6B32 for ; Thu, 20 May 2010 05:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.449 X-Spam-Level: X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_50=0.001, HELO_EQ_FR=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 WTSc9jgghJEe for ; Thu, 20 May 2010 05:40:34 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE993A68C8 for ; Thu, 20 May 2010 05:40:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o4KCeNDK003313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 May 2010 14:40:23 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o4KCeMGP007156 for ; Thu, 20 May 2010 14:40:23 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o4KCeMJF023735 for ; Thu, 20 May 2010 14:40:22 +0200 Message-ID: <4BF52DB6.8050905@gmail.com> Date: Thu, 20 May 2010 14:40:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: <6D9687E95918C04A8B30A7D6DA805A3E0142A175@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A175@zensys17.zensys.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 12:40:35 -0000 Le 19/05/2010 09:39, Anders Brandt a écrit : > All, > >the plan is still to Last Call RPL before the next IETF > I would like to poll the WG on this statement. > The home and building requirements are not met by the current RPL draft > and we have not even started discussing the P2P ID mechanisms in detail - > or frame format modifications for that matter. > Does the WG agree that a RPL spec without support for home and building > applications is acceptable? Only in part because of the failure to meet requirements - I disagree to pursue RPL towards LC before the next IETF: it is way too early. We have wide technical misunderstandings about the scope of this protocol and its applicability. Alex > Thanks, > Anders > > ------------------------------------------------------------------------ > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > Behalf Of *JP Vasseur > *Sent:* Tuesday, May 18, 2010 11:48 > *To:* roll WG > *Subject:* [Roll] RPL Status > > Dear WG, > > Here is a quick status. First, we would like to thank the WG again > for the continuous effort and lots of fruitful and productive work ! > As discussed in Anaheim, the plan is still to Last Call RPL before > the next IETF. The plan is to release the next revision of the RPL > I-D by end of next week. Rev-08 will address the following: > > 1) Security section (integrating the work on the security DT) > 2) New DAO mechanism (cleaner and more simple), as agreed on the > Mailing List > 3) Basic source routing => See also companion drafts to be published > very soon for (RH-0 like) > 4) Updated manageability section > 5) DAO ACK > 6) Trickle algorithm removed from the core specification (in a > separate doc), Examples removed > 7) Several Edits, clarifications, ... > > I had a discussion with David, and the plan is to have the P2P a > separate ID (the current RPL specification provides basic P2P, with > "advanced" P2P defined in that I-D), with the objective to progress > both documents in parallel. > > */What else ?/* > We need to progress a few other documents: > 1) Use of the RPL TLV: see draft-hui-6man-rpl-option (6man WG) > 2) Source routing header (RH-0 like): to be published soon > (Jonathan/David) > 3) RPL Variables (ticket #22) > 4) ID related to measurement from P2P (if consensus on Mailing list) > > Looking forward to your comments as soon as rev-08 will be published. > > Thanks. > > JP and David. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Thu May 20 05:41:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9AE3A6B7C for ; Thu, 20 May 2010 05:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.423 X-Spam-Level: X-Spam-Status: No, score=-0.423 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_50=0.001, HELO_EQ_FR=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 1HnLoFBSomd5 for ; Thu, 20 May 2010 05:41:30 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 5FBBD3A6B5A for ; Thu, 20 May 2010 05:41:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o4KCfLa0004088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 May 2010 14:41:21 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o4KCfKaP007423 for ; Thu, 20 May 2010 14:41:21 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o4KCfKCU024122 for ; Thu, 20 May 2010 14:41:20 +0200 Message-ID: <4BF52DF0.9000307@gmail.com> Date: Thu, 20 May 2010 14:41:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D01E861A6@XMB-AMS-107.cisco.com> <87ljbhytat.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D01E86506@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01E86506@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] RPL multicast (was Re: RPL Status) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 12:41:31 -0000 Le 19/05/2010 14:59, Pascal Thubert (pthubert) a écrit : > Hi Richard: > > MLD requests are effectively turned into DAOs and will reach the root as > you suggest. From there, what do we do in source route? > > The extremes (global flood/prune and as many unicast from the root) seem > both quite easy and quite expansive when applied to the wrong case. > Pruning will require states in the nodes to retain information on the > floods it has already seen and passed along. Certainly we can leave it > up to the root to select either method based on the density of > listeners. > > A real multicast operation in the intermediate nodes in pure source > route would require a new form of RH encoding, that's doable but not > necessarily trivial. Would we want that in the RH spec? > > Finally, if the direction for the future is states in some nodes as we > used to have it, then those can effectively multicast for their > subtrees, so maybe we can keep that piece for later... > > What do you think? What is the multicast support offered by the link layers on which RPL runs? Alex > > Pascal > > >> -----Original Message----- >> From: Richard Kelsey [mailto:richard.kelsey@ember.com] >> Sent: Tuesday, May 18, 2010 8:11 PM >> To: Pascal Thubert (pthubert) >> Cc: jpv@cisco.com; roll@ietf.org >> Subject: RPL multicast (was Re: [Roll] RPL Status) >> >>> Date: Tue, 18 May 2010 18:12:59 +0200 >>> From: "Pascal Thubert (pthubert)" >>> >>>> Richard Kelsey >>>> Sent: Tuesday, May 18, 2010 4:47 PM >>>> >>>> We will have to do something about multicasts (ticket #30). >>>> The multicast text in the current draft has a number of >>>> limitiations; in particular, it requires that all nodes cache > DAOs. >>>> >>>> Forwarding multicasts using unicasts makes sense if relatively few >>>> nodesneed to receive them. For a multicast that needs to get to >>>> most or all of a network, using unicasts seems likely to be both >>>> unreliable and inefficient. >> >>> Good point. Would you have a suggestion for the source route world? >> >> Pascal, >> >> It's a hard problem. >> >> ZigBee, which has always-on routers, uses hop-limited flooding for >> multicasts. This works well for multicasts that need to go to all or > almost all >> nodes. >> >> I do not know how multicasts are handled in sensor networks, where >> flooding is relatively expensive. >> >> In the source route world, for multicasts with few subscribers, the > simplest >> thing would to use DAOs more-or-less as is done for downward routes. > MLD >> requests would be forwarded up to the root, and the root would keep > track >> of which nodes were subscribed to which multicast addresses. > Multicasts >> would be also forwarded to the root, which would unicast them down to >> subscribers. I suppose the root could also make the determination as > to >> which multicasts could be more effectively flooded. >> >> More complicated schemes are possible, but I don't like more > complicated >> schemes :-). >> -Richard Kelsey > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Thu May 20 05:53:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94CCC3A6BC9 for ; Thu, 20 May 2010 05:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_50=0.001, HELO_EQ_FR=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 WlEGs2Pterwe for ; Thu, 20 May 2010 05:53:51 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id EA8243A6AE8 for ; Thu, 20 May 2010 05:53:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o4KCrgAM013291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 May 2010 14:53:42 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o4KCrfNP011810 for ; Thu, 20 May 2010 14:53:42 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o4KCrfMa018075 for ; Thu, 20 May 2010 14:53:41 +0200 Message-ID: <4BF530D5.2040405@gmail.com> Date: Thu, 20 May 2010 14:53:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] The P2P terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 12:53:56 -0000 The P2P term is hardly illustrative for RPL. P2P usually stands for peer-to-peer, often relating to overlay networks, and its often illegal co-notation can't do much good to RPL evangelisation. I suggest finding another term which expresses the need of straight IP communication between two leaves of same parent, or similar. Something more related to the IP routing terminology, rather than P2P networks. (conceptually, a similar context exists with Mobile IP MN-HA-CN and it's called Route Optimization rather than P2P.) A second misunderstanding may arise when talking P2P as point-to-point (not peer-to-peer) - this term has a meaning dangerously similar to P2MP or MP2P. P2P P2MP MP2P are very loosely defined terms in this group. Alex From pal@cs.stanford.edu Thu May 20 10:03:12 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08DA53A6965 for ; Thu, 20 May 2010 10:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.762 X-Spam-Level: X-Spam-Status: No, score=-4.762 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_50=0.001, 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 VO70TtMnojvy for ; Thu, 20 May 2010 10:03:10 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id D90D23A6960 for ; Thu, 20 May 2010 10:03:10 -0700 (PDT) Received: from dnab4046bc.stanford.edu ([171.64.70.188]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OF99D-0003AV-An; Thu, 20 May 2010 10:03:04 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-95--284964464 From: Philip Levis In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A175@zensys17.zensys.local> Date: Thu, 20 May 2010 10:02:58 -0700 Message-Id: <49F7848A-1FAD-4095-AA1A-109A9B0990BF@cs.stanford.edu> References: <6D9687E95918C04A8B30A7D6DA805A3E0142A175@zensys17.zensys.local> To: Anders Brandt X-Mailer: Apple Mail (2.1078) X-Scan-Signature: 8577cc8f8d13cb4ae2b02fc82e253015 Cc: roll WG Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 17:03:12 -0000 --Apple-Mail-95--284964464 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 19, 2010, at 12:39 AM, Anders Brandt wrote: > All, > =20 > >the plan is still to Last Call RPL before the next IETF > =20 > I would like to poll the WG on this statement. > The home and building requirements are not met by the current RPL = draft and we have not even started discussing the P2P ID mechanisms in = detail - > or frame format modifications for that matter. > =20 > Does the WG agree that a RPL spec without support for home and = building applications is acceptable? > =20 > Thanks, I think that a core RFC that does not *include* P2P (home and building = applications) is acceptable. However, it should be that supporting P2P = (described in a separate document) does not require any changes to the = core RFC. E.g., adding more packet types and using reserved bits is OK, = modifying existing packet formats is not. This necessitates that the = core RFC be aware of what P2P needs, although perhaps not every detail = of how it works. It's been two months since Anaheim; from the discussions there I thought = we'd be much further along. The best way to resolve this tension is to = make fast progress on P2P. Phil= --Apple-Mail-95--284964464 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On May 19, 2010, at 12:39 AM, Anders Brandt wrote:

All,
 
>the plan is still to Last Call RPL before the next IETF
 
I would like to poll the WG on this statement.
The home and building requirements are not met by the current RPL draft and we have not even started discussing the P2P ID mechanisms in detail -
or frame format modifications for that matter.
 
Does the WG agree that a RPL spec without support for home and building applications is acceptable?
 
Thanks,

I think that a core RFC that does not *include* P2P (home and building applications) is acceptable. However, it should be that supporting P2P (described in a separate document) does not require any changes to the core RFC. E.g., adding more packet types and using reserved bits is OK, modifying existing packet formats is not. This necessitates that the core RFC be aware of what P2P needs, although perhaps not every detail of how it works.

It's been two months since Anaheim; from the discussions there I thought we'd be much further along. The best way to resolve this tension is to make fast progress on P2P.

Phil
--Apple-Mail-95--284964464-- From pal@cs.stanford.edu Thu May 20 10:12:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC69A3A68D4 for ; Thu, 20 May 2010 10:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.73 X-Spam-Level: X-Spam-Status: No, score=-4.73 tagged_above=-999 required=5 tests=[AWL=-0.731, 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 PRS1A4exCqgH for ; Thu, 20 May 2010 10:12:08 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 8921A3A6893 for ; Thu, 20 May 2010 10:12:08 -0700 (PDT) Received: from dnab4046bc.stanford.edu ([171.64.70.188]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OF9Ht-0003mo-9a; Thu, 20 May 2010 10:12:02 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <352039149.12399081274204469006.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Thu, 20 May 2010 10:12:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <74751AB0-D6BD-48F3-8FC7-AC1CABAE02B5@cs.stanford.edu> References: <352039149.12399081274204469006.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1078) X-Scan-Signature: 182a93e729013cb8e6197caf3eccd507 Cc: roll , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 17:12:10 -0000 On May 18, 2010, at 10:41 AM, Mukul Goyal wrote: > Philip >=20 >>> Note that we chose not to go deep into metrics/"routing cost" = discussion in the p2p draft, simply because different people have very = strong and very different opinions on what is right and what is wrong.=20= >=20 >> I'm sorry; I need to argue this point. This isn't a question of = opinion. It's a question of overwhelming scientific evidence and = deployment experiences from real networks. Here are two simple published = studies[1,2]. >=20 > You are ignoring the fact that there are scenarios (especially, in = home automation environment; Anders may back me up on this), where a = device can not maintain any neighbor-specific state (e.g. the cost of = the link to the neighbor or even the identity of the neighbor). You can = not argue that hop-count should not be used even in such situations. It = may be a bad metric in general but it may still be the only metric that = can be used in a given situation. Why can't a device maintain any neighbor-specific state? We need a = stateless protocol? I do not recall this from the application = requirement documents; please correct me if I'm wrong. >=20 >>> A node should not forward a Discovery message further if it does not = have the relevant link-level cost estimates. >=20 >> I think that is this is changed to MUST NOT, then it could be OK. Or = how about >=20 > "A node MUST NOT forward a Discovery message from a node for which it = does not have relevant link-level metric information." >=20 > I am OK with changing "should not" to "MUST NOT". There is a problem = with the text you suggested. Suppose a _forward_ route is being = discovered as per a certain routing metric. Node B receives a discovery = message from node A. As per your text, node B must not forward the = message further if cost B->A is unavailable/bad. I think you might be reading too much into the text -- "relevant = link-level metric information" could imply A->B or B->A. Hence the word = "relevant." > But, cost B->A is irrelevant in this case. Your text assumes that = routing metrics are symmetrical enough to conclude that link A->B must = be bad if link B->A is bad. Whether this assumption is valid or not = depends on the definition of the routing metric/cost and is not some = thing that should concern the route discovery protocol. The route = discovery protocol needs to be agnostic about the metrics being used. = Would you be OK with the text I suggested with "MUST NOT" replacing = "should not": >=20 > A node MUST NOT forward a Discovery message further if it does not = have the relevant link-level cost estimates. This seems a bit too vague for me -- what link-level cost estimates are = relevant? How about "A node MUST NOT forward a Discovery message from a node if it does not = have relevant link-level metric information for the link between the = two." >=20 >>> Note that we can not really refer to the "neighbor table" as you had = suggested earlier. >=20 >> Why? >=20 > Because, a neighbor table may not exist since nodes are too = constrained to maintain per-neighbor states. The core upward protocol is written under the premise of neighbor sets, = parent sets, and preferred parents; if this terminology is invalid then = we should go back to the drawing board. Can you point me to the document = where this is stated? We can't have it both ways: efficient P2P and no = state. I'd argue that for such nodes, you should route through their = preferred parent. Stateless on-demand is a recipe for disaster. Phil From pal@cs.stanford.edu Thu May 20 10:24:27 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5EB83A6B5A for ; Thu, 20 May 2010 10:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.542 X-Spam-Level: X-Spam-Status: No, score=-4.542 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 LN0kZ6mjL7kE for ; Thu, 20 May 2010 10:24:27 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 165193A69D1 for ; Thu, 20 May 2010 10:22:21 -0700 (PDT) Received: from dnab4046bc.stanford.edu ([171.64.70.188]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OF9Rm-0002E3-L9; Thu, 20 May 2010 10:22:14 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A173@zensys17.zensys.local> Date: Thu, 20 May 2010 10:22:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <50C8A61B-8CD8-44A6-9D54-FE7F19827A1C@cs.stanford.edu> References: <463402115.12177031274165176659.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E0142A173@zensys17.zensys.local> To: Anders Brandt X-Mailer: Apple Mail (2.1078) X-Scan-Signature: 127ff6e1eac6b45a32dc112250ed777d Cc: roll , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 17:24:27 -0000 On May 19, 2010, at 12:25 AM, Anders Brandt wrote: > hi Phil >=20 >> There is extensive empirical evidence that using hopcount is a > terrible idea. >=20 > [Anders]=20 > That may very well be. I suggest we put that terrible idea next to the > extensive evidence that several commercial systems works _GOOD_ENOUGH_ > with simple hop-count COMBINED with the ability to find another route = if > there is a substantial number of retransmissions on that actual route. > The result is terribly inexpensive chips (< $2) with radio, RAM, CPU = and > everything onboard. Consumers want this! Sure -- "if there is a substantial number of retransmissions" is link = validation. But I'm not sure I understand the argument: even though = there's a way to avoid NUD and route rediscovery, we shouldn't use it? = Or is the concern that the link metric constraint might lead to a = disconnected graph? >=20 >> If the routing metric is hop-count then the LLN will not work well; >> you are better off routing up and down the DAG >=20 > [Anders]=20 > With these small nodes, the only DAG information maintained in > individual nodes is the DODAGID + source routes a few other nodes that > the node is supposed to control in some way. Yes, then there are some > few nodes which can do a "Turn a lot of nodes off". They will have = more > RAM + non-volatile memory but we SHOULD NOT put that burden on all = nodes > in the network. (sorry for SHOUTING but we should really not ignore = the > extensive evidence of the successfull deployment of millions of these > extemely inexpensive chips out there) These nodes do not have neighbor sets? How do they join a DODAG? Does = the home and building automation RFC state that a neighbor set of size 1 = is a requirement for RPL? Should it? Phil From Jerald.P.Martocci@jci.com Thu May 20 11:19:06 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DD393A6844; Thu, 20 May 2010 11:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 aqdGXIvctxZW; Thu, 20 May 2010 11:19:02 -0700 (PDT) Received: from exprod8og102.obsmtp.com (exprod8og102.obsmtp.com [64.18.3.84]) by core3.amsl.com (Postfix) with ESMTP id B80593A682D; Thu, 20 May 2010 11:19:00 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob102.postini.com ([64.18.7.12]) with SMTP ID DSNKS/V9CWryXuSkswMCWV8Ab4+PBVX2yv0G@postini.com; Thu, 20 May 2010 11:18:54 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010052013191148-2341942 ; Thu, 20 May 2010 13:19:11 -0500 In-Reply-To: <50C8A61B-8CD8-44A6-9D54-FE7F19827A1C@cs.stanford.edu> References: <463402115.12177031274165176659.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E0142A173@zensys17.zensys.local> <50C8A61B-8CD8-44A6-9D54-FE7F19827A1C@cs.stanford.edu> To: Philip Levis MIME-Version: 1.0 X-KeepSent: D50C6B75:D1BDDB03-86257729:0063C2EA; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 20 May 2010 13:18:40 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 05/20/2010 01:18:47 PM, Serialize complete at 05/20/2010 01:18:47 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/20/2010 01:19:11 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/20/2010 01:19:18 PM, Serialize complete at 05/20/2010 01:19:18 PM Content-Type: text/html; charset="US-ASCII" Cc: roll-bounces@ietf.org, Emmanuel Baccelli , roll Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 18:19:06 -0000
Hi Phil,

For Commercial requirements, I can afford to keep neighbor information.  A reason amount of properties for maybe 10 neighbors.  However, I need to be able to cull the list of neighbors as needed to fit in my available RAM.  So if there are 30 nodes within radio range and hence potential neighbors, I may only support a subset of those nodes as neighbors.  Typically, this will be based on routes I am already supporting or signal strength.  

This is how our current ZigBee product (AODV) operates.  Since AODV has little control packet overhead this works well.  I am concerned with the proactive use of DIOs and DAOs in RPL, I may not be able to support as many neighbors since it may impact my processing power needed for my primary building application.

Jerry





From: Philip Levis <pal@cs.stanford.edu>
To: Anders Brandt <abr@sdesigns.dk>
Cc: roll <roll@ietf.org>, Emmanuel Baccelli <emmanuel.baccelli@inria.fr>
Date: 05/20/2010 12:24 PM
Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00





On May 19, 2010, at 12:25 AM, Anders Brandt wrote:

> hi Phil
>
>> There is extensive empirical evidence that using hopcount is a
> terrible idea.
>
> [Anders]
> That may very well be. I suggest we put that terrible idea next to the
> extensive evidence that several commercial systems works _GOOD_ENOUGH_
> with simple hop-count COMBINED with the ability to find another route if
> there is a substantial number of retransmissions on that actual route.
> The result is terribly inexpensive chips (< $2) with radio, RAM, CPU and
> everything onboard. Consumers want this!

Sure -- "if there is a substantial number of retransmissions" is link validation. But I'm not sure I understand the argument: even though there's a way to avoid NUD and route rediscovery, we shouldn't use it? Or is the concern that the link metric constraint might lead to a disconnected graph?


>
>> If the routing metric is hop-count then the LLN will not work well;
>> you are better off routing up and down the DAG
>
> [Anders]
> With these small nodes, the only DAG information maintained in
> individual nodes is the DODAGID + source routes a few other nodes that
> the node is supposed to control in some way. Yes, then there are some
> few nodes which can do a "Turn a lot of nodes off". They will have more
> RAM + non-volatile memory but we SHOULD NOT put that burden on all nodes
> in the network. (sorry for SHOUTING but we should really not ignore the
> extensive evidence of the successfull deployment of millions of these
> extemely inexpensive chips out there)

These nodes do not have neighbor sets? How do they join a DODAG? Does the home and building automation RFC state that a neighbor set of size 1 is a requirement for RPL? Should it?

Phil



_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

From jpv@cisco.com Thu May 20 12:56:42 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3CB3A6AB3 for ; Thu, 20 May 2010 12:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.764 X-Spam-Level: X-Spam-Status: No, score=-7.764 tagged_above=-999 required=5 tests=[AWL=0.235, 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 dfaXme28oK0P for ; Thu, 20 May 2010 12:56:41 -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 9D6583A6A51 for ; Thu, 20 May 2010 12:56:41 -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: AvsEAOsw9UurRN+K/2dsb2JhbACeFnGlbJlZhRIEjz0 X-IronPort-AV: E=Sophos;i="4.53,273,1272844800"; d="scan'208";a="200398271" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 20 May 2010 19:56:35 +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 o4KJuYqS003483; Thu, 20 May 2010 19:56:34 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 21:56:33 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 21:56:33 +0200 Message-Id: From: JP Vasseur To: Mukul Goyal In-Reply-To: <268872740.13130131274319544778.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 20 May 2010 21:56:17 +0200 References: <268872740.13130131274319544778.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 May 2010 19:56:33.0307 (UTC) FILETIME=[8BFE86B0:01CAF856] Cc: Emmanuel Baccelli , roll WG Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 19:56:42 -0000 Hi Mukul, On May 20, 2010, at 3:39 AM, Mukul Goyal wrote: > Hi JP > > [Mukul] >> Here is a list of the controls that can be used to limit the spread >> of discovery messages: >> >> 1. If a node does not know the link cost, it wont forward the >> discovery message further (was implicit in the p2p draft; now would >> be made explicit); >> 2. If a node receives a discovery message advertizing a rank (in the >> temporary DAG) higher than the node's current rank, the discovery >> message is ignored; >> 3. If the discovery message has already traveled a certain >> "distance" (determined based on the rank that the receiving node >> would achieve in the temporary DAG using the rank advertized in the >> discovery message), it wont be forwarded any further; >> 4. If the end-to-end cost for the path taken by the discovery >> message so far already fails the "good enough" criteria, the >> discovery message is not forwarded any further; (this control is >> optional since the "good enough" criteria may be too difficult for a >> constrained intermediate node to calculate) > > [JP] > Note that there are quite a few vague/hard to define parameters: > "Certain" distance, "good enough" that will require more detailed > explanations. > > [Mukul] > The "distance" that the discovery messages may travel would be > represented by a maximum limit on the rank in the temporary DAG. > This maximum limit on rank I suppose is a configuration parameter. > The "good enough" criteria may be tied up to the e2e cost of any > existing DAG-based route or it could be a configuration parameter as > well. > > Do you think that these two concepts are not well described in the > draft? There are described. If the document is adopted I'll make a detailed pass at WG chair shepherd and provide comments, suggest text, ... Note one thing though. Be cautious not to end up with a mechanism with a large number of parameters the value of which would be difficult to determine. > > [JP] >> 5. The trickle timer. >> > > See my previous message .... you may because of that ignore a "better" > path, the whole reason for using this P2P scheme. > > [Mukul] > Not sure how. A node would always generate a discovery message at > the (periodic) expiry of the trickle timer if it has a better cost > to advertize (unless the local policy some how prevents it from > doing so). > You just need to add a criteria to the trickle timers reset. > [JP] >> The trickle timer helps control the spread of discovery messages in >> following ways: >> 1. The timer's interval can be chosen to "speed up" the discovery >> message or "slow it" down; the tradeoff being the number of >> discovery messages generated. A large interval allows only one >> message to be sent in response to several received. >> 2. The redundancy threshold of the trickle timer can optionally be >> used to further limit the generation of discovery messages. Do not >> generate your own discovery message if you have already received "n" >> messages advertizing the same/better rank or e2e cost than what you >> will advertize. >> > > Not a showstopper by all means but still lots of knobs difficult to > define ... > > [Mukul] > But these knobs are standard/integral part of a trickle timer. > Again just be cautious not to add too many. Bear in mind, that recommended values should be provide before any IESG LC. Thanks. JP. > Thanks > Mukul > From jpv@cisco.com Thu May 20 12:56:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A773A6B90 for ; Thu, 20 May 2010 12:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.14 X-Spam-Level: X-Spam-Status: No, score=-8.14 tagged_above=-999 required=5 tests=[AWL=0.600, 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 HnG-O7Zc2E6E for ; Thu, 20 May 2010 12:56:47 -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 C73943A6846 for ; Thu, 20 May 2010 12:56:46 -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: AvsEAHIw9UtAZnwM/2dsb2JhbACeFnGlZJlfhRIE X-IronPort-AV: E=Sophos;i="4.53,273,1272844800"; d="scan'208";a="113039683" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 20 May 2010 19:56:39 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4KJucTx000937; Thu, 20 May 2010 19:56:39 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 21:56:38 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 21:56:38 +0200 Message-Id: <55BFBD59-FFA6-42FB-865E-58653F2712F4@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01E86506@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 20 May 2010 21:56:22 +0200 References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D01E861A6@XMB-AMS-107.cisco.com> <87ljbhytat.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D01E86506@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 May 2010 19:56:38.0604 (UTC) FILETIME=[8F26C8C0:01CAF856] Cc: roll@ietf.org Subject: Re: [Roll] RPL multicast (was Re: RPL Status) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 19:56:48 -0000 Hi, On May 19, 2010, at 2:59 PM, Pascal Thubert (pthubert) wrote: > Hi Richard: > > MLD requests are effectively turned into DAOs and will reach the > root as > you suggest. From there, what do we do in source route? > > The extremes (global flood/prune and as many unicast from the root) > seem > both quite easy and quite expansive when applied to the wrong case. > Pruning will require states in the nodes to retain information on the > floods it has already seen and passed along. Certainly we can leave it > up to the root to select either method based on the density of > listeners. > > A real multicast operation in the intermediate nodes in pure source > route would require a new form of RH encoding, that's doable but not > necessarily trivial. Would we want that in the RH spec? => This is what I was referring as a technique that was used for P2MP Traffic Engineering LSP using RSVP, but be careful this means lots of overhead ... That would not be in our charter too. > > Finally, if the direction for the future is states in some nodes as we > used to have it, then those can effectively multicast for their > subtrees, so maybe we can keep that piece for later... I think so too ... > > What do you think? > > Pascal > > >> -----Original Message----- >> From: Richard Kelsey [mailto:richard.kelsey@ember.com] >> Sent: Tuesday, May 18, 2010 8:11 PM >> To: Pascal Thubert (pthubert) >> Cc: jpv@cisco.com; roll@ietf.org >> Subject: RPL multicast (was Re: [Roll] RPL Status) >> >>> Date: Tue, 18 May 2010 18:12:59 +0200 >>> From: "Pascal Thubert (pthubert)" >>> >>>> Richard Kelsey >>>> Sent: Tuesday, May 18, 2010 4:47 PM >>>> >>>> We will have to do something about multicasts (ticket #30). >>>> The multicast text in the current draft has a number of >>>> limitiations; in particular, it requires that all nodes cache > DAOs. >>>> >>>> Forwarding multicasts using unicasts makes sense if relatively few >>>> nodesneed to receive them. For a multicast that needs to get to >>>> most or all of a network, using unicasts seems likely to be both >>>> unreliable and inefficient. >> >>> Good point. Would you have a suggestion for the source route world? >> >> Pascal, >> >> It's a hard problem. >> >> ZigBee, which has always-on routers, uses hop-limited flooding for >> multicasts. This works well for multicasts that need to go to all or > almost all >> nodes. >> >> I do not know how multicasts are handled in sensor networks, where >> flooding is relatively expensive. >> >> In the source route world, for multicasts with few subscribers, the > simplest >> thing would to use DAOs more-or-less as is done for downward routes. > MLD >> requests would be forwarded up to the root, and the root would keep > track >> of which nodes were subscribed to which multicast addresses. > Multicasts >> would be also forwarded to the root, which would unicast them down to >> subscribers. I suppose the root could also make the determination as > to >> which multicasts could be more effectively flooded. >> >> More complicated schemes are possible, but I don't like more > complicated >> schemes :-). >> -Richard Kelsey > From jpv@cisco.com Thu May 20 12:56:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9447A3A6B87 for ; Thu, 20 May 2010 12:56:50 -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.359, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] 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 A962qPbsuXqx for ; Thu, 20 May 2010 12:56:49 -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 2679F3A6846 for ; Thu, 20 May 2010 12:56:49 -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: AvsEAHIw9UtAZnwN/2dsb2JhbACeFnGlZJlfhRIE X-IronPort-AV: E=Sophos;i="4.53,273,1272844800"; d="scan'208";a="113039693" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 May 2010 19:56:42 +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 o4KJugTM013886; Thu, 20 May 2010 19:56:42 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 21:56:41 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 21:56:41 +0200 Message-Id: From: JP Vasseur To: Anders Brandt In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A173@zensys17.zensys.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 20 May 2010 21:56:25 +0200 References: <463402115.12177031274165176659.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E0142A173@zensys17.zensys.local> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 May 2010 19:56:41.0463 (UTC) FILETIME=[90DB0870:01CAF856] Cc: Emmanuel Baccelli , roll Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 19:56:50 -0000 Very useful feed-back from experience. One quick comment though: I completely understand your motivation for a reactive approach so as to avoid a "simple" device to maintain routing states and make it reachable quickly even if it has not maintained states for some time. On the path quality front, the argument becomes indeed a bit less compelling when the routing metrics itself may not really reflect the path quality. That said, make it metric agnostic, referring to the metric-ID (so does RPL) and you will be fine. Thanks. JP. On May 19, 2010, at 9:25 AM, Anders Brandt wrote: > hi Phil > >> There is extensive empirical evidence that using hopcount is a > terrible idea. > > [Anders] > That may very well be. I suggest we put that terrible idea next to the > extensive evidence that several commercial systems works _GOOD_ENOUGH_ > with simple hop-count COMBINED with the ability to find another > route if > there is a substantial number of retransmissions on that actual route. > The result is terribly inexpensive chips (< $2) with radio, RAM, CPU > and > everything onboard. Consumers want this! > >> If the routing metric is hop-count then the LLN will not work well; >> you are better off routing up and down the DAG > > [Anders] > With these small nodes, the only DAG information maintained in > individual nodes is the DODAGID + source routes a few other nodes that > the node is supposed to control in some way. Yes, then there are some > few nodes which can do a "Turn a lot of nodes off". They will have > more > RAM + non-volatile memory but we SHOULD NOT put that burden on all > nodes > in the network. (sorry for SHOUTING but we should really not ignore > the > extensive evidence of the successfull deployment of millions of these > extemely inexpensive chips out there) > >> The protocol can't have it both ways: argue that it quickly detects > "good enough" routes with low stretch yet also needs to >> support detecting terrible routes. > > [Anders] > The nice thing about the P2P ID proposal is that you can specify in > the > discovery if you are in a hurry and just want the first route that can > turn on your lamp or if you are on a quest for "good" routes; i.e. can > live with having to wait for a number of discovery responses before > you > pick the best - out of your metrics criteria. > > Cheers, > Anders > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of Philip Levis >> Sent: Tuesday, May 18, 2010 17:39 >> To: Mukul Goyal >> Cc: roll; Emmanuel Baccelli >> Subject: Re: [Roll] Fwd: New Version Notification >> fordraft-dt-roll-p2p-rpl-00 >> >> On May 17, 2010, at 11:46 PM, Mukul Goyal wrote: >> >>> [Mukul] >>> I agree that a node should forward a Discovery message only >> if it has a good estimate of the "link cost in the right >> direction". I guess this can be made explicit in the draft. >> But, the routing metric may simply be hop-count, in which >> case the receipt of the Discovery message is a reasonable >> proof of the existence of the "hop". So, I won't say that >> receiving a discovery packet is always insufficient to >> determine the "link cost" value. It really depends on the >> definition of the routing cost. >> >> There is extensive empirical evidence that using hopcount is >> a terrible idea. If the routing metric is hop-count then the >> LLN will not work well; you are better off routing up and >> down the DAG than dynamically discovering routes. The >> protocol can't have it both ways: argue that it quickly >> detects "good enough" routes with low stretch yet also needs >> to support detecting terrible routes. >> >> Hopcount as a metric is a myth that entered our imagination >> due to terrible wireless simulations. It is a simplification >> that does not work. Let's move past the 1990s and stop >> considering hopcount as something that RPL needs to >> accommodate. Remember, we're talking about LLNs: Lossy and >> Low Power Networks. >> >> Phil >> _______________________________________________ >> 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 jpv@cisco.com Thu May 20 12:57:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD6E3A6846 for ; Thu, 20 May 2010 12:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.093 X-Spam-Level: X-Spam-Status: No, score=-9.093 tagged_above=-999 required=5 tests=[AWL=1.462, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 ukPCd1PmQVe8 for ; Thu, 20 May 2010 12:57:24 -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 947AC3A6A35 for ; Thu, 20 May 2010 12:57:24 -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: AlQGAG4x9UurR7Hu/2dsb2JhbAAunWhxpW2ZWYUSBI89 X-IronPort-AV: E=Sophos;i="4.53,273,1272844800"; d="scan'208";a="257087950" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 20 May 2010 19:57:16 +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 o4KJvGdB017291; Thu, 20 May 2010 19:57:18 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 21:57:16 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 21:57:16 +0200 Message-Id: <07916D32-0CAA-491C-B4B8-913DE9BC5FEA@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <1387149801.13120851274317512178.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 20 May 2010 18:09:15 +0200 References: <1387149801.13120851274317512178.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 May 2010 19:57:16.0745 (UTC) FILETIME=[A5E2A390:01CAF856] Cc: Emmanuel Baccelli , roll Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 19:57:25 -0000 Thanks Mukul, On May 20, 2010, at 3:05 AM, Mukul Goyal wrote: > Hi JP, > >>>> A node should not forward a Discovery message further if it does >>>> not have the relevant link-level cost estimates. >> > [Philip] >>> I think that is this is changed to MUST NOT, then it could be OK. >>> Or how about >> >> "A node MUST NOT forward a Discovery message from a node for which >> it does not have relevant link-level metric information." >> > > [Mukul] >> I am OK with changing "should not" to "MUST NOT". There is a problem >> with the text you suggested. Suppose a _forward_ route is being >> discovered as per a certain routing metric. Node B receives a >> discovery message from node A. As per your text, node B must not >> forward the message further if cost B->A is unavailable/bad. But, >> cost B->A is irrelevant in this case. Your text assumes that routing >> metrics are symmetrical enough to conclude that link A->B must be >> bad if link B->A is bad. Whether this assumption is valid or not >> depends on the definition of the routing metric/cost and is not some >> thing that should concern the route discovery protocol. The route >> discovery protocol needs to be agnostic about the metrics being used. > >> Would you be OK with the text I suggested with "MUST NOT" replacing >> "should not": >> > > [JP] > Yes, just add a short justification. > > [Mukul] > > Will do. > > Thanks > Mukul > >> A node MUST NOT forward a Discovery message further if it does not >> have the relevant link-level cost estimates. >> From jpv@cisco.com Thu May 20 12:57:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6E13A6BC0 for ; Thu, 20 May 2010 12:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.122 X-Spam-Level: X-Spam-Status: No, score=-9.122 tagged_above=-999 required=5 tests=[AWL=1.433, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 NgfZSfqAbwzo for ; Thu, 20 May 2010 12:57:35 -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 871983A6846 for ; Thu, 20 May 2010 12:57:34 -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: AlQGAG4x9UtAZnwN/2dsb2JhbAAunWhxpW2ZWYUSBI89 X-IronPort-AV: E=Sophos;i="4.53,273,1272844800"; d="scan'208";a="113039952" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 May 2010 19:57:15 +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 o4KJvFoq014393; Thu, 20 May 2010 19:57:15 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 21:57:15 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 21:57:14 +0200 Message-Id: <943C1FF7-57F3-4EEB-9D4B-5EEF8A4311C7@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <926259539.13118641274316960978.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 20 May 2010 17:44:17 +0200 References: <926259539.13118641274316960978.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 May 2010 19:57:14.0776 (UTC) FILETIME=[A4B63180:01CAF856] Cc: roll Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 19:57:37 -0000 Hi Mukul, On May 20, 2010, at 2:56 AM, Mukul Goyal wrote: > Hi JP > >> 6) We just need to have a section somewhere indicating that such >> reactive mechanism has a cost too and the resulting > path cost decrease is not known a priori and may end up being close > to the DAG cost for that destination. I am not > questioning the usefulness of the mechanism, just make sure to > indicate it. > > >> I can help provide some text, if that helps. > > Sure, please send me the text you would like to see in the draft. Will do. I'll wait until you provide the next revision and I'll provide you some text. > Also, I wanted to point out that the purpose of the measurement > messages is to help decide whether to initiate a reactive route > discovery ot not. If the measurement of the cost of an existing (DAG- > based) route indicates that this route is good enough, there wont be > a need to do a reactive discovery. Understood, that does not remove the challenge of "what good enough" means, especially when you have a route that is neither bad nor excellent. You may end generating traffic to measure the DAG route via the measurement mechanism, potential trigger the reactive mechanisms and end up with a route that is not "much" better. No show-stopper, we just need to make it clear in the specification. > Further, the "good enough" criteria can be selected on the basis of > information provided by measurement messages. If the measurement on > a DAG-based route returns an end-to-end cost "x", the good enough > criteria can be set to some fraction of x thereby ensuring that any > discovered P2P routes have a certain minimum cost advantage over DAG- > based route. But you can only compare once you have both routes. > Ofcourse, there may not exist any P2P routes with such advantage > (and that's why we need to put in the text that you are suggesting). > Exactly. I'll provide some text for the next revision. Thanks. JP. > Thanks > Mukul > > > ----- Original Message ----- > From: "JP Vasseur" > To: "Anders Brandt" > Cc: "Mukul Goyal" , "roll" > Sent: Tuesday, May 18, 2010 11:01:57 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll- > p2p-rpl-00 > > Hi Anders, > > > > On May 17, 2010, at 4:18 PM, Anders Brandt wrote: > > > > > Hi JP > > > > > Please find comments inline > > > - Anders > > > > > > From: JP Vasseur [ mailto:jpv@cisco.com ] > Sent: Monday, May 17, 2010 15:05 > To: Anders Brandt; Mukul Goyal > Cc: roll > Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll- > p2p-rpl-00 > > > Hi Anders, > > > Co-chair hat-off. > > > I think that it goes in right direction. > > > Few comments for the moment. > > > 1) o The constraint to route only along a DAG leading to > significantly suboptimal P2P routes and traffic congestion near the > DAG root. > JP> You may want to soften the statement here since the path > computed along the DAG > may be sub-optimal .. it all depends on the destination, degree of > meshing of the DAG, etc ... > I think that the argument of not having to maintain route > maintenance for some nodes is > more compelling. > > > > What about: > "The constraint to route only along a DAG potentially leading to > significantly > suboptimal P2P routes and traffic congestion near the DAG root." ? > > OK > > > > > > > 2) Such applications require a mechanism for "reactive route > discovery" and the ability to route "across DAGs". > > > JP> Why is it required to route across DAGs ? I guess that you meant > "non DAG" routes ? > > Agreed. What the text should say is: > "across a DAG", "across the branches of a dag" or "along non-DAG > routes" (pick one) > > > I would choose "non DAG route" > > > > > > > > 3) The mechanisms described in this document are intended to be > employed as complementary to RPL in specific scenarios that need > point-to- > point (P2P) routes between arbitrary nodes. > > > JP> More specifically, I think that we agree that it will be part of > RPL, as an optional mechanism. > > Negative. > > RPL will never be able to deliver the required performance for home > and > building without decent support for battery operation and reactive > self-healing. > > > You misunderstood my point. The WG agreed that this was a MUST, I am > not questioning the usefulness > of it. I just meant to say that all implementations will not need > it, that's all (thus the term optional). > > > > > > > > > 4) Section 4.2: objective function > > > JP> You actually do not need an OF for that. Just use the metrics > specified in the Routing-metrics ID, > adding a path-cost-bound object (for the "good enough" criteria). > > > > > Great. This is an example of why it will be valuable for RPL as a > whole if the WG starts discussing > how to achieve the stated goals of the draft. > OF or metrics - I leave it for the experts to decide which is the > right thing. As long as I can ask for a > "good enough" route as result of a reactive discovery. I need the > lamp to turn on with low delay. > Later, I may have time for fine-tuning the route. > > > We're in sync. > > > > > > > > > > > > 5) 4.6. Transport of Routing Metrics The Metric Container option > defined in RPL-07 can be used to carry > both the aggregated end-to-end and the local values for the routing > metrics being used to define the routing cost. Additional metric > objects may need to be defined to carry the aggregated end-to-end > routing cost and a source-route unmodified from one node to another; > > > JP> with regards to the second part of the paragraph I would suggest > to use the same metrics as defined > in the routing-metric ID. > > > 6) We just need to have a section somewhere indicating that such > reactive mechanism has a cost too and the resulting > path cost decrease is not known a priori and may end up being close > to the DAG cost for that destination. I am not > questioning the usefulness of the mechanism, just make sure to > indicate it. > > > I can help provide some text, if that helps. > > > Thanks. > > > JP. > > > > > > Thanks. > > > JP. > > > On May 17, 2010, at 9:28 AM, Anders Brandt wrote: > > > > > Hi all > > The P2P draft has been out for some weeks now. > The team would like to poll the WG for directions whether this is > the right approach. > > > > Phil has indicated some agreement. > What about the rest of the WG? > > Others in favour of the work? > Any alternative proposals? > > Otherwise the P2P team will conclude that we are on the right track > and go on proposing specific frame format additions/modifications > and mechanisms for RPL. > When the required maturity is reached, those proposed additions/ > changes > should be adopted by the RPL spec; thus obsoleting this draft. > > Thanks, > Anders > > > > > On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote: > > > > > > > > Hi all > > > > > > > > > > The following draft has been submitted for WG's consideration. It > > > > > describes the additional mechanisms required to support P2P > > > routing in > > > > > LLNs. The draft first provides a high level description of the > > > > > mechanisms and then proposes one way of realizing these > > > mechanisms in > > > > > RPL. > > > > > > > > > > Regards > > > > > Mukul > > > > > > > > > > ----- Forwarded Message ----- > > > > > From: "IETF I-D Submission Tool" < idsubmission@ietf.org > > > > > > To: mukul@uwm.edu > > > > > Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada > > > > > Central > > > > > Subject: New Version Notification for draft-dt-roll-p2p-rpl-00 > > > > > > > > > > > > > > > A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been > > > > > successfully submitted by Mukul Goyal and posted to the IETF > > > > > repository. > > > > > > > > > > Filename: draft-dt-roll-p2p-rpl > > > > > Revision: 00 > > > > > Title: Mechanisms to Support Point-to-Point > > > Routing in Low Power > > > > > and Lossy Networks > > > > > Creation_date: 2010-04-28 > > > > > WG ID: Independent Submission > > > > > Number_of_pages: 13 > > > > > > > > > > Abstract: > > > > > This draft presents mechanisms to determine the end-to-end > > > cost of an > > > > > existing route and to discover/establish "on demand" one or more > > > > > routes between two nodes in a low power and lossy network. > > > This draft > > > > > also proposes functionality that would enable RPL to > > > provide these P2P > > > > > mechanisms. > > > > > > > > > > > > > > > > > > > > The IETF Secretariat. > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 prvs=749dee93c=mukul@uwm.edu Thu May 20 15:16:20 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E57E3A69FC for ; Thu, 20 May 2010 15:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[AWL=-0.112, 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 TciWiClEYKI2 for ; Thu, 20 May 2010 15:16:19 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 2B69D3A69B2 for ; Thu, 20 May 2010 15:16:16 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 20 May 2010 17:16:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 614EB2C3800E; Thu, 20 May 2010 17:16:10 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2faNuJPMnPP; Thu, 20 May 2010 17:16:10 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 29B972C38015; Thu, 20 May 2010 17:16:10 -0500 (CDT) Date: Thu, 20 May 2010 17:15:40 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1624888289.13532501274393738475.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <890229550.13528681274393128389.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 22:16:20 -0000 Hi Philip [Mukul1] >>> Note that we chose not to go deep into metrics/"routing cost" discussion in the p2p draft, simply because different people have very strong and very different opinions on what is right and what is wrong. > [Philip1] >> I'm sorry; I need to argue this point. This isn't a question of opinion. It's a question of overwhelming scientific evidence and deployment experiences from real networks. Here are two simple published studies[1,2]. > [Mukul2] > You are ignoring the fact that there are scenarios (especially, in home automation environment; Anders may back me up on this), where a device can not maintain any neighbor-specific state (e.g. the cost of the link to the neighbor or even the identity of the neighbor). You can not argue that hop-count should not be used even in such situations. It may be a bad metric in general but it may still be the only metric that can be used in a given situation. [Philip2] Why can't a device maintain any neighbor-specific state? We need a stateless protocol? I do not recall this from the application requirement documents; please correct me if I'm wrong. [Mukul3] I think this discussion is going on wrong track. The route discovery mechanism needs to be metric agnostic. The route discovery protocol can not preclude the use of certain metrics, even the bad ones. ***************************************************************************************************** > [Mukul1] >>> A node should not forward a Discovery message further if it does not have the relevant link-level cost estimates. > [Philip1] >> I think that is this is changed to MUST NOT, then it could be OK. Or how about > > "A node MUST NOT forward a Discovery message from a node for which it does not have relevant link-level metric information." > [Mukul2] > I am OK with changing "should not" to "MUST NOT". There is a problem with the text you suggested. Suppose a _forward_ route is being discovered as per a certain routing metric. Node B receives a discovery message from node A. As per your text, node B must not forward the message further if cost B->A is unavailable/bad. [Philip2] I think you might be reading too much into the text -- "relevant link-level metric information" could imply A->B or B->A. Hence the word "relevant." [Mukul2] > But, cost B->A is irrelevant in this case. Your text assumes that routing metrics are symmetrical enough to conclude that link A->B must be bad if link B->A is bad. Whether this assumption is valid or not depends on the definition of the routing metric/cost and is not some thing that should concern the route discovery protocol. The route discovery protocol needs to be agnostic about the metrics being used. Would you be OK with the text I suggested with "MUST NOT" replacing "should not": > > A node MUST NOT forward a Discovery message further if it does not have the relevant link-level cost estimates. [Philip2] This seems a bit too vague for me -- what link-level cost estimates are relevant? How about "A node MUST NOT forward a Discovery message from a node if it does not have relevant link-level metric information for the link between the two." [Mukul3] So, the underlying assumption is that if node B receives a discovery message from node A, the relevant (A->B or B->A) link cost information would be available on B?? If this assumption is perceived as valid for all metrics, I am OK with your text. Infact, in that case, the assumption would need to go in text as well. But then we will be making an assumption about the routing metrics that can be used. I think my text is better even though vague. ******************************************************************************************************* > [Mukul1] >>> Note that we can not really refer to the "neighbor table" as you had suggested earlier. > [Philip1] >> Why? > [Mukul2] > Because, a neighbor table may not exist since nodes are too constrained to maintain per-neighbor states. [Philip3] The core upward protocol is written under the premise of neighbor sets, parent sets, and preferred parents; if this terminology is invalid then we should go back to the drawing board. Can you point me to the document where this is stated? We can't have it both ways: efficient P2P and no state. I'd argue that for such nodes, you should route through their preferred parent. Stateless on-demand is a recipe for disaster. [Mukul3] I do not see a need to _require_ neighbor tables for the reactive route disovery part. Neighbor tables are _required_ to maintain link-level values for certain routing metrics. But, the reactive route discovery part has to be metric agnostic. I am going to go back to RPL specs to see the context in which it refers to the neighbor tables. May be we will have another point to argue about. ;) Thanks Mukul From prvs=749dee93c=mukul@uwm.edu Thu May 20 15:20:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADF2B3A6971 for ; Thu, 20 May 2010 15:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[AWL=-0.112, 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 yrwDfhs4Mwzn for ; Thu, 20 May 2010 15:20:31 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id EF6B83A6A27 for ; Thu, 20 May 2010 15:20:28 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 20 May 2010 17:20:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 679D82C38018; Thu, 20 May 2010 17:20:22 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou8eU4Loiu6B; Thu, 20 May 2010 17:20:22 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 2A04B2C38017; Thu, 20 May 2010 17:20:22 -0500 (CDT) Date: Thu, 20 May 2010 17:18:57 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1000827988.13533161274393937384.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 22:20:31 -0000 Hi Philip [Mukul1] >>> Note that we chose not to go deep into metrics/"routing cost" discussion in the p2p draft, simply because different people have very strong and very different opinions on what is right and what is wrong. > [Philip1] >> I'm sorry; I need to argue this point. This isn't a question of opinion. It's a question of overwhelming scientific evidence and deployment experiences from real networks. Here are two simple published studies[1,2]. > [Mukul2] > You are ignoring the fact that there are scenarios (especially, in home automation environment; Anders may back me up on this), where a device can not maintain any neighbor-specific state (e.g. the cost of the link to the neighbor or even the identity of the neighbor). You can not argue that hop-count should not be used even in such situations. It may be a bad metric in general but it may still be the only metric that can be used in a given situation. [Philip2] Why can't a device maintain any neighbor-specific state? We need a stateless protocol? I do not recall this from the application requirement documents; please correct me if I'm wrong. [Mukul3] I think this discussion is going on wrong track. The route discovery mechanism needs to be metric agnostic. The route discovery protocol can not preclude the use of certain metrics, even the bad ones. ***************************************************************************************************** > [Mukul1] >>> A node should not forward a Discovery message further if it does not have the relevant link-level cost estimates. > [Philip1] >> I think that is this is changed to MUST NOT, then it could be OK. Or how about > > "A node MUST NOT forward a Discovery message from a node for which it does not have relevant link-level metric information." > [Mukul2] > I am OK with changing "should not" to "MUST NOT". There is a problem with the text you suggested. Suppose a _forward_ route is being discovered as per a certain routing metric. Node B receives a discovery message from node A. As per your text, node B must not forward the message further if cost B->A is unavailable/bad. [Philip2] I think you might be reading too much into the text -- "relevant link-level metric information" could imply A->B or B->A. Hence the word "relevant." [Mukul2] > But, cost B->A is irrelevant in this case. Your text assumes that routing metrics are symmetrical enough to conclude that link A->B must be bad if link B->A is bad. Whether this assumption is valid or not depends on the definition of the routing metric/cost and is not some thing that should concern the route discovery protocol. The route discovery protocol needs to be agnostic about the metrics being used. Would you be OK with the text I suggested with "MUST NOT" replacing "should not": > > A node MUST NOT forward a Discovery message further if it does not have the relevant link-level cost estimates. [Philip2] This seems a bit too vague for me -- what link-level cost estimates are relevant? How about "A node MUST NOT forward a Discovery message from a node if it does not have relevant link-level metric information for the link between the two." [Mukul3] So, the underlying assumption is that if node B receives a discovery message from node A, the relevant (A->B or B->A) link cost information would be available on B?? If this assumption is perceived as valid for all metrics, I am OK with your text. Infact, in that case, the assumption would need to go in text as well. But then we will be making an assumption about the routing metrics that can be used. I think my text is better even though vague. ******************************************************************************************************* > [Mukul1] >>> Note that we can not really refer to the "neighbor table" as you had suggested earlier. > [Philip1] >> Why? > [Mukul2] > Because, a neighbor table may not exist since nodes are too constrained to maintain per-neighbor states. [Philip3] The core upward protocol is written under the premise of neighbor sets, parent sets, and preferred parents; if this terminology is invalid then we should go back to the drawing board. Can you point me to the document where this is stated? We can't have it both ways: efficient P2P and no state. I'd argue that for such nodes, you should route through their preferred parent. Stateless on-demand is a recipe for disaster. [Mukul3] I do not see a need to _require_ neighbor tables for the reactive route disovery part. Neighbor tables are _required_ to maintain link-level values for certain routing metrics. But, the reactive route discovery part has to be metric agnostic. I am going to go back to RPL specs to see the context in which it refers to the neighbor tables. May be we will have another point to argue about. ;) Thanks Mukul From samitac@ipinfusion.com Thu May 20 20:35:59 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43F3B3A7144 for ; Thu, 20 May 2010 20:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_50=0.001, HTML_MESSAGE=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 vbQxFoOh4LCr for ; Thu, 20 May 2010 20:35:50 -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 E98043A6DF2 for ; Thu, 20 May 2010 19:29:02 -0700 (PDT) Received: (qmail 10053 invoked from network); 21 May 2010 02:28:54 -0000 Received: from (samitac@65.223.109.250 with login) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 20 May 2010 19:28:54 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: S066ByQVM1lPeXvOAY1Nip7QdQP6JR68sTfAqSQI7HWx5DrJYJbk9RG8GYB4ETPtjLAbOg4E8FgSrhYERAfgeSRK._SN1EZZqZNnaSLksxcufEWORA2DRJSYVS.o2o.tqN8nz2J2tC.7q5FaRwd.Ac.PJ95wy___0FPKwbzurLouIg1JZBOysN2wU7_ZYOsGDGGmJFnNGjIsVvFQkPtd8hxpzsgeBBFvaTV3k9ovDc6XmmlS1ABIIy675P2H.MMUk4H8hobkLowSqWgecrDkRAFSqsl7giy. X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> In-Reply-To: Date: Thu, 20 May 2010 19:28:53 -0700 Message-ID: <039a01caf88d$5b4e5d60$11eb1820$@com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_039B_01CAF852.AEEF8560" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr3d4sUtVufDqBRTQS+1HicHSdTKABE1htg Content-Language: en-us Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 03:35:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_039B_01CAF852.AEEF8560 Content-Type: multipart/alternative; boundary="----=_NextPart_001_039C_01CAF852.AEEF8560" ------=_NextPart_001_039C_01CAF852.AEEF8560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jerald, Thanks for the response. Please see below. With regards to multicast being a separate ID, it concerns me that if we proliferate IDs some may naturally atrophy or be discounted in time. I believe that RPL should cover all the necessary IP functionality as applied to LLNs including multicast and P2P operations. If a given implementation determines that for whatever reason the application does not need these features, then they need not be implemented. However, I think the RFC should be holistic. That being said, please note that I am a complete IETF neophyte. Maybe there are ways to assure that separate ID stay in lock-step. If this is true then I have no qualms about separate IDs. If there is a chance that some IDs may fall into disrepair, then I opt for a single fully inclusive RPL ID. [SC>] There is no generic rules on id separations in IETF. But, I was fearing that including all feature in one protocol draft may complicate the progress of the draft. But I was pointed out that multicast is in the RPL charter; in that respect we may want to have limited multicast forwarding support in LLN for now. Later, if needed one can extend the feature for more efficiency of multicast in LLN. Moreover in some L2-networks like 802.15.4, there is no multicast support at the link-layer - in those cases, unicasts and broad-casts are the only options depending on the applications - right? With regards to multicast in building environments, currently there are two multicast use cases used in building control. The first is for discovery purposes. There is a need for a device to access data items from other devices. The discovery and binding is done using a site multicast (or broadcast). Often times the binding will be across two devices in the same LLN, however, it's very possible that the binding may cross subnets. A case in point is the need to access the 'outdoor air temperature'. This data is very important to the HVAC control algorithms. However, buildings typically only deploy a single outdoor air temperature sensor across the entire enterprise. Hence most references to the device will cross subnets. [SC>] Thanks for the real-life example - very useful. Can I assume that an enterprise will have a collection of LLNs joined by their border routers in the backbone? The second use case will be for different building subsystems (e.g. Fire, Security, HVAC) to operate independently at the application layer, but to share the routing (meshing) capability to increase the density of the meshing nodes. [SC>] So, in this example, is it fair to say that the main usage would be to address all-node-multicast in a building sub-system? Or there might be more granular usage of multicast groups (per floor, per room etc.)? Thanks again, -Samita From: "Samita Chakrabarti" To: "'Richard Kelsey'" , "'JP Vasseur'" Cc: roll@ietf.org Date: 05/18/2010 06:56 PM Subject: Re: [Roll] RPL Status _____ Hi Richard/JP, > > > > Here is a quick status. First, we would like to thank the WG again for > > the continuous effort and lots of fruitful and productive work ! As > > discussed in Anaheim, the plan is still to Last Call RPL before the > > next IETF. > > We will have to do something about multicasts (ticket #30). > The multicast text in the current draft has a number of limitiations; in > particular, it requires that all nodes cache DAOs. > [SC>] Ticket #30 is about clarification of text regarding the multicast operation. Indeed it is not clear and subject to implementor's interpretation. > Forwarding multicasts using unicasts makes sense if relatively few nodes > need to receive them. For a multicast that needs to get to most or all of a > network, using unicasts seems likely to be both unreliable and inefficient. > [SC>] BTW, is RPL also trying to solve multicast routing/forwarding completely in all cases ? It might be better to have another id for the detailed multicast forwarding/routing for all cases (multicast to all nodes in LLN, multicast to nodes that are spread out under different parents far from each other and trying communicate with each other etc.). It might be easier for RPL draft to handle a set of common use cases with the existing mechanism. I wonder what would be the typical applications today for RPL in LLN ? Is it in the building network where most of the communication takes place from one or two parent or grand-parent nodes to their descendants using a multi-cast address? That said, we also need to make sure the current multicast mechanism could be extended to cover other scenarios. Actually the current solution of using DAO to store the multicast address and the corresponding members of the multicast address may work out. But I agree it is more work on each parent node to aggregate the multicast addresses, process them and store them and might also make a decision to prune. If we consider LLN to be a route-over only link, then modifying MLD hop-limit and forwarding MLD messages are an option but we still need to consider pruning. A generic solution for multicast routing/forwarding in LLN seems to be a non-trivial problem to be handled in RPL draft alone. Thanks, -Samita _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_001_039C_01CAF852.AEEF8560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 =

Hi Jerald,

 =

Thanks for the  response. Please see below.


With = regards to multicast being a separate ID, it concerns me that if we proliferate IDs = some may naturally atrophy or be discounted in time.  I believe that RPL = should cover all the necessary IP functionality as applied to LLNs including = multicast and P2P operations.  If a given implementation determines that for whatever reason the application does not need these features, then they = need not be implemented.  However, I think the RFC should be = holistic.

That = being said, please note that I am a complete IETF neophyte.  Maybe there = are ways to assure that separate ID stay in lock-step.  If this is true = then I have no qualms about separate IDs.  If there is a chance that some = IDs may fall into disrepair, then I opt for a single fully inclusive RPL = ID.

[SC>]  There is no = generic rules on id separations in IETF. But, I was fearing that including all = feature in one protocol draft may complicate the progress of the draft. =  But I was pointed out that multicast is in the RPL charter; in that respect we may = want to have  limited multicast forwarding support in LLN for now. = Later, if needed one can extend the feature for more efficiency of multicast in = LLN. Moreover in some L2-networks like 802.15.4, there is no multicast = support at the link-layer – in those cases, unicasts and broad-casts are the = only options depending on the applications – = right?



With = regards to multicast in building environments, currently there are two multicast = use cases used in building control.  The first is for discovery purposes.  There is a need for a device to access data items from other = devices.  The discovery and binding is done using a site multicast (or = broadcast).  Often times the binding will be across two devices in the same = LLN, however, it's very possible that the binding may cross subnets.  A = case in point is the need to access the 'outdoor air temperature'.  This = data is very important to the HVAC control algorithms.  However, buildings typically only deploy a single outdoor air temperature sensor across the = entire enterprise.  Hence most references to the device will cross = subnets.

[SC>] Thanks for the = real-life example – very useful. Can I assume that an enterprise will have a collection of LLNs joined by their border routers in the = backbone?


The = second use case will be for different building subsystems (e.g. Fire, Security, = HVAC) to operate independently at the application layer, but to share the routing (meshing) capability to increase the density of the meshing = nodes.


[SC>] So, in this example, = is it fair to say that the main usage would be to address all-node-multicast = in a building sub-system? Or there might be more granular usage of multicast = groups (per floor, per room etc.)?




Thanks = again,

-Samita<= /b>






From:

"Samita Chakrabarti" <samitac@ipinfusion.com> =

To:

"'Richard= Kelsey'" <richard.kelsey@ember.com>, "'JP = Vasseur'" <jpv@cisco.com>

Cc:

roll@ietf.org<= /span>

Date:

05/18/2010 06:56 PM

Subject:

Re: [Roll] RPL Status

 





Hi Richard/JP,

> >
> > Here is a quick status. First, we would like to thank the = WG again for
> > the continuous effort and lots of fruitful and productive = work ! As
> > discussed in Anaheim, the plan is still to Last Call RPL = before the
> > next IETF.
>
> We will have to do something about multicasts (ticket = #30).
> The multicast text in the current draft has a number of = limitiations; in
> particular, it requires that all nodes cache DAOs.
>
[SC>]  Ticket #30 is about clarification of text regarding = the multicast
operation.
Indeed it is not clear and subject to implementor's = interpretation.

> Forwarding multicasts using unicasts makes sense if relatively = few nodes
> need to receive them.  For a multicast that needs to get = to most or all of
a
> network, using unicasts seems likely to be both unreliable = and
inefficient.
>

[SC>] BTW, is RPL also trying to solve multicast = routing/forwarding
completely in all cases ? It might be better to have another id for = the
detailed multicast forwarding/routing for all cases (multicast to = all nodes
in LLN, multicast to nodes that are spread out under different = parents far
from each other and trying communicate with each other etc.). It = might be
easier for RPL draft to handle a set of common use cases with the = existing
mechanism. I wonder what would be the typical applications today for = RPL in
LLN ? Is it in the building network where most of the communication = takes
place from one or two parent or grand-parent nodes to their = descendants
using a multi-cast address?
That said, we also need to make sure the current multicast mechanism = could
be extended to cover other scenarios.

Actually the current solution of using DAO to store the multicast = address
and the corresponding members of the multicast address may work out. = But I
agree it is more work on each parent node to aggregate the = multicast
addresses, process them and store them and might also make a = decision to
prune.

If we consider LLN to be a route-over only link, then modifying = MLD
hop-limit and forwarding MLD messages are an option but we still = need to
consider pruning.
A generic solution for multicast routing/forwarding in LLN seems to = be a
non-trivial problem to be handled in RPL draft alone.

Thanks,
-Samita



_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------=_NextPart_001_039C_01CAF852.AEEF8560-- ------=_NextPart_000_039B_01CAF852.AEEF8560 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= ------=_NextPart_000_039B_01CAF852.AEEF8560-- From geoff@proto6.com Fri May 21 03:04:19 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5363A6872 for ; Fri, 21 May 2010 03:04:19 -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 NCmBosiPrRW4 for ; Fri, 21 May 2010 03:04:18 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 136683A9216 for ; Thu, 20 May 2010 23:50:09 -0700 (PDT) Received: from server1.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 920E3181A8 for ; Fri, 21 May 2010 00:50:14 -0600 (MDT) Received: from [199.233.92.21] (dev21.coslabs.com [199.233.92.21]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o4L6o19h027241 for ; Fri, 21 May 2010 00:50:02 -0600 (MDT) From: Geoff Mulligan To: roll@ietf.org In-Reply-To: <039a01caf88d$5b4e5d60$11eb1820$@com> References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> <039a01caf88d$5b4e5d60$11eb1820$@com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 21 May 2010 00:50:05 -0600 Message-ID: <1274424605.3101.128.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [Roll] whither draft-ietf-roll-protocols-survey-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 10:04:19 -0000 What ever happened to the protocol survey draft? Samita's message about the proliferation of drafts that atrophy got me wondering about the protocol survey draft. This is a working group document and is part of the milestones and charter of the ROLL WG, but this draft has long since expired. It was supposed to be submitted to the IESG as an informational RFC back in Feb 2009. It was last updated in April of 2009 so I would think that it is complete. Why hasn't it been submitted to the IESG? Given that it was THIS document that was the basis for the decision to create a new routing protocol it is important that this information is not lost. Did the WG ever even Last Call this document? geoff From jpv@cisco.com Fri May 21 07:58:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90DE3A718E for ; Fri, 21 May 2010 07:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.182 X-Spam-Level: X-Spam-Status: No, score=-9.182 tagged_above=-999 required=5 tests=[AWL=1.417, 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 3tY-aNYjmHWY for ; Fri, 21 May 2010 07:58:35 -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 26B483A7865 for ; Fri, 21 May 2010 03:25:21 -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: AvsEANP89UurR7H+/2dsb2JhbACeIHGjNplahRIE X-IronPort-AV: E=Sophos;i="4.53,277,1272844800"; d="scan'208";a="533147071" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 21 May 2010 10:25: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 o4LAPEq2017811; Fri, 21 May 2010 10:25:14 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 12:25:13 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 12:25:12 +0200 Message-Id: <115B81B3-7678-4293-BE38-F35E7ACA2D8D@cisco.com> From: JP Vasseur To: Geoff Mulligan In-Reply-To: <1274424605.3101.128.camel@d430> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 21 May 2010 12:25:12 +0200 References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> <039a01caf88d$5b4e5d60$11eb1820$@com> <1274424605.3101.128.camel@d430> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 May 2010 10:25:13.0223 (UTC) FILETIME=[E5E29170:01CAF8CF] Cc: roll@ietf.org Subject: Re: [Roll] whither draft-ietf-roll-protocols-survey-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 14:58:35 -0000 On May 21, 2010, at 8:50 AM, Geoff Mulligan wrote: > What ever happened to the protocol survey draft? > > Samita's message about the proliferation of drafts that atrophy got me > wondering about the protocol survey draft. This is a working group > document and is part of the milestones and charter of the ROLL WG, but > this draft has long since expired. > > It was supposed to be submitted to the IESG as an informational RFC > back > in Feb 2009. It was last updated in April of 2009 so I would think > that > it is complete. Why hasn't it been submitted to the IESG? Given that > it was THIS document that was the basis for the decision to create a > new > routing protocol it is important that this information is not lost. > > Did the WG ever even Last Call this document? The decision was made not to publish it as an RFC (see WG minutes), also in agreement with our AD. This will be reflected in the Milestone when we will work on them, with the WG. Thanks. JP. > > geoff > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Fri May 21 07:59:15 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37203A67B7 for ; Fri, 21 May 2010 07:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.208 X-Spam-Level: X-Spam-Status: No, score=-9.208 tagged_above=-999 required=5 tests=[AWL=1.390, 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 5AREgBM5TJYB for ; Fri, 21 May 2010 07:59:14 -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 093CB3A857F for ; Fri, 21 May 2010 03:26:29 -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: AvsEANP89UurR7Hu/2dsb2JhbACeIHGjNplahRIEj0Q X-IronPort-AV: E=Sophos;i="4.53,277,1272844800"; d="scan'208,217";a="533147809" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 21 May 2010 10:26:23 +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 o4LAQ3vH025593; Fri, 21 May 2010 10:26:22 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 12:26:20 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 12:26:19 +0200 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: <49F7848A-1FAD-4095-AA1A-109A9B0990BF@cs.stanford.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-185--222364245 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 21 May 2010 12:26:19 +0200 References: <6D9687E95918C04A8B30A7D6DA805A3E0142A175@zensys17.zensys.local> <49F7848A-1FAD-4095-AA1A-109A9B0990BF@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 May 2010 10:26:20.0036 (UTC) FILETIME=[0DB56C40:01CAF8D0] Cc: roll WG Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 14:59:15 -0000 --Apple-Mail-185--222364245 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 20, 2010, at 7:02 PM, Philip Levis wrote: > > On May 19, 2010, at 12:39 AM, Anders Brandt wrote: > >> All, >> >> >the plan is still to Last Call RPL before the next IETF >> >> I would like to poll the WG on this statement. >> The home and building requirements are not met by the current RPL >> draft and we have not even started discussing the P2P ID mechanisms >> in detail - >> or frame format modifications for that matter. >> >> Does the WG agree that a RPL spec without support for home and >> building applications is acceptable? >> >> Thanks, > > I think that a core RFC that does not *include* P2P (home and > building applications) is acceptable. However, it should be that > supporting P2P (described in a separate document) does not require > any changes to the core RFC. E.g., adding more packet types and > using reserved bits is OK, modifying existing packet formats is not. > This necessitates that the core RFC be aware of what P2P needs, > although perhaps not every detail of how it works. > > It's been two months since Anaheim; from the discussions there I > thought we'd be much further along. The best way to resolve this > tension is to make fast progress on P2P. Absolutely. JP. > > Phil --Apple-Mail-185--222364245 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On May 20, 2010, = at 7:02 PM, Philip Levis wrote:


On May 19, 2010, = at 12:39 AM, Anders Brandt wrote:

All,
 
>the plan is still to Last Call RPL = before the next IETF
 
I = would like to poll the WG on this = statement.
The = home= and building requirements are not met by the current RPL draft and we = have not even started discussing the P2P ID mechanisms in detail = -
or frame format modifications for that = matter.
 
=
Does the WG agree that a RPL spec without = support for home and building = applications is acceptable?
=
 
Thanks,

I think that a core RFC that does = not *include* P2P (home and building applications) is acceptable. = However, it should be that supporting P2P (described in a separate = document) does not require any changes to the core RFC. E.g., adding = more packet types and using reserved bits is OK, modifying existing = packet formats is not. This necessitates that the core RFC be aware of = what P2P needs, although perhaps not every detail of how it = works.

It's been two months since Anaheim; from = the discussions there I thought we'd be much further along. The best way = to resolve this tension is to make fast progress on = P2P.

Absolutely.
JP.

List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 15:53:05 -0000 This is a multi-part message in MIME format. --------------080100080704010404020508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit One would expect that draft to have progressed and be published already. If it is open for discussion again then I have comments on it. Last I remember is public discussion in february 2009 - it ended with a Chair statement intenting to use this draft as a motivation to recharter and develop new protocol... Then echoes were heard publicly about private discussion on this draft (discussion about which we don't know much), and then silence since april 25th, 2009. Recharter happened. Document to IESG didn't seem so. It's strange. Alex Le 21/05/2010 08:50, Geoff Mulligan a écrit : > What ever happened to the protocol survey draft? > > Samita's message about the proliferation of drafts that atrophy got > me wondering about the protocol survey draft. This is a working > group document and is part of the milestones and charter of the ROLL > WG, but this draft has long since expired. > > It was supposed to be submitted to the IESG as an informational RFC > back in Feb 2009. It was last updated in April of 2009 so I would > think that it is complete. Why hasn't it been submitted to the IESG? > Given that it was THIS document that was the basis for the decision > to create a new routing protocol it is important that this > information is not lost. > > Did the WG ever even Last Call this document? > > geoff > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > --------------080100080704010404020508 Content-Type: message/rfc822; name="Message joint" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Message joint" Received: from levau.intra.cea.fr ([132.166.88.52]) by LODERI.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Apr 2009 04:09:25 +0200 Received: from muguet2.intra.cea.fr ([132.166.192.7]) by levau.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.3959); Sat, 25 Apr 2009 04:09:24 +0200 Received: from epeire3.extra.cea.fr (epeire3.extra.cea.fr [132.168.224.5]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-in-1.1) with ESMTP id n3P29OCS015410 for ; Sat, 25 Apr 2009 04:09:24 +0200 Received: from oxalide.extra.cea.fr (oxalide.extra.cea.fr [132.168.224.2]) by epeire3.extra.cea.fr (8.14.2/8.14.2) with ESMTP id n3P29O3h011347 for ; Sat, 25 Apr 2009 04:09:24 +0200 (envelope-from alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com) Received: from relay2-v.mail.gandi.net (relay2-v.mail.gandi.net [217.70.178.76]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-in-2.0) with ESMTP id n3P27FAC005823 for ; Sat, 25 Apr 2009 04:07:20 +0200 Received: from spool.mail.gandi.net (mspool2-v.mgt.gandi.net [10.0.21.72]) by relay2-v.mail.gandi.net (Postfix) with ESMTP id 05D5F135D7; Sat, 25 Apr 2009 04:09:19 +0200 (CEST) Received: from localhost (mfilter6-d.gandi.net [217.70.178.40]) by spool.mail.gandi.net (Postfix) with ESMTP id E93E332C07E; Sat, 25 Apr 2009 04:09:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter6-v.mgt.gandi.net Received: from spool.mail.gandi.net ([10.0.21.72]) by localhost (mfilter6-d.mgt.gandi.net [217.70.178.40]) (amavisd-new, port 10024) with ESMTP id v25UKvLgLKMp; Sat, 25 Apr 2009 04:09:16 +0200 (CEST) X-GreyListed: -750/725491 seconds (209.85.218.170:greylisted until 04/25/09 01:14) Received: from mail-bw0-f170.google.com (mail-bw0-f170.google.com [209.85.218.170]) by spool.mail.gandi.net (Postfix) with ESMTP id C355432C07B for ; Sat, 25 Apr 2009 04:09:16 +0200 (CEST) Received: by bwz18 with SMTP id 18so1334545bwz.3 for ; Fri, 24 Apr 2009 19:09:16 -0700 (PDT) Received: by 10.223.126.66 with SMTP id b2mr1090827fas.18.1240625356487; Fri, 24 Apr 2009 19:09:16 -0700 (PDT) X-Forwarded-To: alexandru.petrescu@incognitus.eu X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@incognitus.eu Delivered-To: alexandru.petrescu@gmail.com Received: by 10.223.111.143 with SMTP id s15cs85410fap; Fri, 24 Apr 2009 19:09:16 -0700 (PDT) Received: by 10.220.100.139 with SMTP id y11mr5744020vcn.117.1240625354727; Fri, 24 Apr 2009 19:09:14 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id 6si1968223ywc.51.2009.04.24.19.09.09; Fri, 24 Apr 2009 19:09:14 -0700 (PDT) Received-SPF: pass (google.com: domain of roll-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of roll-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=roll-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59AB3A6A01; Fri, 24 Apr 2009 19:07:49 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D343D3A69DB for ; Fri, 24 Apr 2009 19:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 XlMiut3BNPhW for ; Fri, 24 Apr 2009 19:07:48 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 1F49E3A63EC for ; Fri, 24 Apr 2009 19:07:46 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.105]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LxXKD-0007Fd-3C for roll@ietf.org; Fri, 24 Apr 2009 19:09:05 -0700 Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <20090424211501.62C363A6C3A@core3.amsl.com> References: <20090424211501.62C363A6C3A@core3.amsl.com> Message-Id: From: Philip Levis Date: Fri, 24 Apr 2009 19:08:42 -0700 To: ROLL WG X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Subject: Re: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org X-CEA-Source: externe X-CEA-Spam: 8% X-CEA-Spam-Report: The following antispam rules were triggered by this message: Rule Score Description BODY_SIZE_2000_2999 0.000 Message body size is 2000 to 2999 bytes BODY_SIZE_5000_LESS 0.000 Message body size is less than 5000 bytes. BODY_SIZE_7000_LESS 0.000 Message body size is less than 5000 bytes. X-CEA-Spam-Hits: BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_LIST_HEADER 0, __HAS_LIST_HELP 0, __HAS_LIST_SUBSCRIBE 0, __HAS_LIST_UNSUBSCRIBE 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MSGID_APPLEMAIL 0, __PHISH_SUBJ_PHRASE5 0, __SANE_MSGID 0, __TO_MALFORMED_2 0 Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com X-OriginalArrivalTime: 25 Apr 2009 02:09:24.0410 (UTC) FILETIME=[DAB1B1A0:01C9C54A] On Apr 24, 2009, at 2:15 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > Title : Overview of Existing Routing Protocols for Low Power and > Lossy Networks > Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis > Filename : draft-ietf-roll-protocols-survey-07.txt > Pages : 26 > Date : 2009-4-24 > > Low-power wireless devices, such as sensors, actuators and smart > objects, present difficult constraints: very limited memory, little > processing power, and long sleep periods. As most of these devices > are battery-powered, energy efficiency is critically important. > Wireless link qualities can vary significantly over time, requiring > protocols to make agile decisions yet minimize topology change > energy > costs. Routing over such low power and lossy networks introduces > requirements that existing routing protocols may not fully address. > Using existing application requirements documents, this document > derives a minimal and not exhaustive set of criteria for routing in > low-power and lossy networks. It provides a brief survey of the > strengths and weaknesses of existing protocols with respect to > these > criteria. From this survey it examines whether existing and mature > IETF protocols can be used without modification in these > networks, or > whether further work is necessary. It concludes that no existing > IETF protocol meets the requirements of this domain. There is one minor change in -07; DYMO's analysis for "node cost" is now "?" rather than "fail." Ian is very certain that DYMO could meet this criterion somehow. We therefore think it's safer to make it "?": there is a possibility that the criterion could be met within the specification, but doing so would require further investigation and specification. As there's consensus on the conclusion of the document, it seems more important to have it on the permanent record as an RFC which we can reference than spin on details. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --------------080100080704010404020508-- From jpv@cisco.com Fri May 21 09:28:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C303A704D for ; Fri, 21 May 2010 09:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.934 X-Spam-Level: X-Spam-Status: No, score=-7.934 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_50=0.001, 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 bj2NxWeNa04T for ; Fri, 21 May 2010 09:28:24 -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 8079728CA3B for ; Fri, 21 May 2010 08:36:45 -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: AvsEAMZE9kurR7H+/2dsb2JhbACeIHGkD4tUjhaFEgQ X-IronPort-AV: E=Sophos;i="4.53,279,1272844800"; d="scan'208,217";a="328161886" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 21 May 2010 15:36:39 +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 o4LFacnm029940; Fri, 21 May 2010 15:36:38 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 17:36:37 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 17:36:36 +0200 Message-Id: <6F6D0CF1-A454-4591-B5D2-302529D5A861@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4BF52DB6.8050905@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-193--214508336 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 21 May 2010 14:37:14 +0200 References: <6D9687E95918C04A8B30A7D6DA805A3E0142A175@zensys17.zensys.local> <4BF52DB6.8050905@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 May 2010 15:36:37.0231 (UTC) FILETIME=[666BEFF0:01CAF8FB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17398.000 X-TM-AS-Result: No--18.605100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 16:28:25 -0000 --Apple-Mail-193--214508336 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Alex, Few comments. Last calling the base specification does not imply by =20 all means that the work is complete, we have other items in our charter, could be re-chartered according to =20= the WG's feed-back, etc ... We were referring to the base RPL specification and for that we have a =20= ticket opened that helps us track that the base specification meets the requirements spelled =20 out in the four requirements document. For the record, I'll resend the document, that will be =20 updated after each revision of RPL. As pointed out by Phil, if we can move forward with P2P I-D that'd be =20= great. Thanks. JP and David. On May 20, 2010, at 2:40 PM, Alexandru Petrescu wrote: > Le 19/05/2010 09:39, Anders Brandt a =E9crit : >> All, >> >the plan is still to Last Call RPL before the next IETF >> I would like to poll the WG on this statement. >> The home and building requirements are not met by the current RPL =20 >> draft >> and we have not even started discussing the P2P ID mechanisms in =20 >> detail - >> or frame format modifications for that matter. >> Does the WG agree that a RPL spec without support for home and =20 >> building >> applications is acceptable? > > Only in part because of the failure to meet requirements - I =20 > disagree to pursue RPL towards LC before the next IETF: it is way =20 > too early. > > We have wide technical misunderstandings about the scope of this =20 > protocol and its applicability. > > Alex > >> Thanks, >> Anders >> >> =20 >> = ------------------------------------------------------------------------ >> *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On >> Behalf Of *JP Vasseur >> *Sent:* Tuesday, May 18, 2010 11:48 >> *To:* roll WG >> *Subject:* [Roll] RPL Status >> >> Dear WG, >> >> Here is a quick status. First, we would like to thank the WG again >> for the continuous effort and lots of fruitful and productive =20 >> work ! >> As discussed in Anaheim, the plan is still to Last Call RPL before >> the next IETF. The plan is to release the next revision of the RPL >> I-D by end of next week. Rev-08 will address the following: >> >> 1) Security section (integrating the work on the security DT) >> 2) New DAO mechanism (cleaner and more simple), as agreed on the >> Mailing List >> 3) Basic source routing =3D> See also companion drafts to be =20 >> published >> very soon for (RH-0 like) >> 4) Updated manageability section >> 5) DAO ACK >> 6) Trickle algorithm removed from the core specification (in a >> separate doc), Examples removed >> 7) Several Edits, clarifications, ... >> >> I had a discussion with David, and the plan is to have the P2P a >> separate ID (the current RPL specification provides basic P2P, =20 >> with >> "advanced" P2P defined in that I-D), with the objective to =20 >> progress >> both documents in parallel. >> >> */What else ?/* >> We need to progress a few other documents: >> 1) Use of the RPL TLV: see draft-hui-6man-rpl-option (6man WG) >> 2) Source routing header (RH-0 like): to be published soon >> (Jonathan/David) >> 3) RPL Variables (ticket #22) >> 4) ID related to measurement from P2P (if consensus on Mailing =20 >> list) >> >> Looking forward to your comments as soon as rev-08 will be =20 >> published. >> >> Thanks. >> >> JP and David. >> >> >> >> _______________________________________________ >> 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 --Apple-Mail-193--214508336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

Few = comments. Last calling the base specification does not imply by all = means that the work is complete,
we have other items in our = charter, could be re-chartered according to the WG's feed-back, etc = ...
We were referring to the base RPL = specification and for that we have a ticket opened that = helps
us track that the base specification meets the = requirements spelled out in the four = requirements 
document. For the record, I'll resend = the document, that will be updated after each revision of = RPL.
As pointed out by Phil, if we can move forward with P2P = I-D that'd be = great.

Thanks.

JP and = David.

On May 20, 2010, at 2:40 PM, Alexandru = Petrescu wrote:

Le 19/05/2010 09:39, Anders Brandt a =E9crit = :
All,
>the plan is still to Last Call RPL before the next = IETF
I would like to poll the = WG on this statement.
The home = and building requirements are not met by the current RPL = draft
and we have not even = started discussing the P2P ID mechanisms in detail = -
or frame format = modifications for that matter.
Does the WG agree that a RPL spec without support for home = and building
applications is = acceptable?

Only in part because of the failure to = meet requirements - I disagree to pursue RPL towards LC before the next = IETF: it is way too early.

We have wide technical = misunderstandings about the scope of this protocol and its = applicability.

Alex

Thanks,
Anders

=    --------------------------------------------------------= ----------------
=    *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = *On
   Behalf = Of *JP Vasseur
=    *Sent:* Tuesday, May 18, 2010 = 11:48
   *To:* = roll WG
=    *Subject:* [Roll] RPL = Status

=    Dear WG,

=    Here is a quick status. First, we would like to thank = the WG again
=    for the continuous effort and lots of fruitful and = productive work !
=    As discussed in Anaheim, the plan is still to Last = Call RPL before
=    the next IETF. The plan is to release the next = revision of the RPL
=    I-D by end of next week. Rev-08 will address the = following:

=    1) Security section (integrating the work on the = security DT)
=    2) New DAO mechanism (cleaner and more simple), as = agreed on the
=    Mailing List
=    3) Basic source routing =3D> See also companion = drafts to be published
=    very soon for (RH-0 like)
   4) Updated manageability = section
   5) = DAO ACK
   6) = Trickle algorithm removed from the core specification (in = a
   separate = doc), Examples removed
=    7) Several Edits, clarifications, = ...

   I had a discussion with David, and the = plan is to have the P2P a
=    separate ID (the current RPL specification provides = basic P2P, with
=    "advanced" P2P defined in that I-D), with the = objective to progress
=    both documents in = parallel.

=    */What else ?/*
   We need to progress a few other = documents:
=    1) Use of the RPL TLV: see draft-hui-6man-rpl-option = (6man WG)
=    2) Source routing header (RH-0 like): to be published = soon
=    (Jonathan/David)
   3) RPL Variables (ticket = #22)
   4) ID = related to measurement from P2P (if consensus on Mailing = list)

=    Looking forward to your comments as soon as rev-08 = will be published.

=    Thanks.

=    JP and David.



_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll


_________________________= ______________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-193--214508336-- From geoff@proto6.com Fri May 21 11:02:42 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 967473A73D8 for ; Fri, 21 May 2010 11:02:42 -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 Wc2vwnutiHtM for ; Fri, 21 May 2010 11:02:41 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 8557F3A80DA for ; Fri, 21 May 2010 06:50:12 -0700 (PDT) Received: from server1.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id AFEEF181A8; Fri, 21 May 2010 07:50:22 -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 o4LDo5l1029706; Fri, 21 May 2010 07:50:05 -0600 (MDT) From: Geoff Mulligan To: JP Vasseur In-Reply-To: <115B81B3-7678-4293-BE38-F35E7ACA2D8D@cisco.com> References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> <039a01caf88d$5b4e5d60$11eb1820$@com> <1274424605.3101.128.camel@d430> <115B81B3-7678-4293-BE38-F35E7ACA2D8D@cisco.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 21 May 2010 07:50:10 -0600 Message-ID: <1274449810.1673.14.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] whither draft-ietf-roll-protocols-survey-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 18:02:42 -0000 WOW. I'll go look - I certainly don't remember this. Was this decided on the mailing list???? Again, I don't remember any mailing list discussion. Something like this should not be decided at a IETF meeting (indicted by your use of the word "minutes"). I think that it is a real shame and mistake that the only document that is the basis for the decision to invent a new protocol and the work that went into that document will be lost if it not published. Which AD approved this action and again was this published on the mailing list? I'll go look. geoff On Fri, 2010-05-21 at 12:25 +0200, JP Vasseur wrote: > On May 21, 2010, at 8:50 AM, Geoff Mulligan wrote: > > > What ever happened to the protocol survey draft? > > > > Samita's message about the proliferation of drafts that atrophy got me > > wondering about the protocol survey draft. This is a working group > > document and is part of the milestones and charter of the ROLL WG, but > > this draft has long since expired. > > > > It was supposed to be submitted to the IESG as an informational RFC > > back > > in Feb 2009. It was last updated in April of 2009 so I would think > > that > > it is complete. Why hasn't it been submitted to the IESG? Given that > > it was THIS document that was the basis for the decision to create a > > new > > routing protocol it is important that this information is not lost. > > > > Did the WG ever even Last Call this document? > > The decision was made not to publish it as an RFC (see WG minutes), also > in agreement with our AD. > > This will be reflected in the Milestone when we will work on them, > with the WG. > > Thanks. > > JP. > > > > > geoff > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Fri May 21 11:38:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E043A68D4 for ; Fri, 21 May 2010 11:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.119 X-Spam-Level: X-Spam-Status: No, score=-5.119 tagged_above=-999 required=5 tests=[AWL=-1.120, 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 QfDBgvaYS5ak for ; Fri, 21 May 2010 11:38:01 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 5212D3A70BB for ; Fri, 21 May 2010 09:25:52 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OFV2f-0002A7-OH; Fri, 21 May 2010 09:25:45 -0700 In-Reply-To: <1624888289.13532501274393738475.JavaMail.root@mail02.pantherlink.uwm.edu> References: <1624888289.13532501274393738475.JavaMail.root@mail02.pantherlink.uwm.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1D8E58B7-A92A-481A-A18E-299AF84DDD07@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Fri, 21 May 2010 09:25:44 -0700 To: Mukul Goyal X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: bd70d0bdda1312c8b25f7b39d1e2fb7f Cc: roll , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 18:38:02 -0000 On May 20, 2010, at 3:15 PM, Mukul Goyal wrote: >> > [Mukul2] >> You are ignoring the fact that there are scenarios (especially, in >> home automation environment; Anders may back me up on this), where >> a device can not maintain any neighbor-specific state (e.g. the >> cost of the link to the neighbor or even the identity of the >> neighbor). You can not argue that hop-count should not be used >> even in such situations. It may be a bad metric in general but it >> may still be the only metric that can be used in a given situation. > > [Philip2] > Why can't a device maintain any neighbor-specific state? We need a > stateless protocol? I do not recall this from the application > requirement documents; please correct me if I'm wrong. > > [Mukul3] I think this discussion is going on wrong track. The route > discovery mechanism needs to be metric agnostic. The route > discovery protocol can not preclude the use of certain metrics, > even the bad ones. I have to disagree that this is the wrong track. It seems like a novel requirement has appeared, and this requirement is the justification for a technical decision. I'm wary of this, as it could be a post-facto justification for a particular approach. If it is a real requirement, then we need to examine the rest of the protocol in light of it. For example, if a node only has a single node in its neighbor set, then datapath validation may not work very well. Phil From jpv@cisco.com Fri May 21 12:20:04 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684403A680F for ; Fri, 21 May 2010 12:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.935 X-Spam-Level: X-Spam-Status: No, score=-7.935 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_50=0.001, 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 dGNrqm0+f3K4 for ; Fri, 21 May 2010 12:20:01 -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 CD4A73A6B7E for ; Fri, 21 May 2010 09:05:39 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAIpF9ktAZnwM/2dsb2JhbACBP5xhcaQFmWuFEgQ X-IronPort-AV: E=Sophos;i="4.53,279,1272844800"; d="pdf'?scan'208,217";a="113480649" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 21 May 2010 15:36:53 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4LFaIwv006629; Fri, 21 May 2010 15:36:53 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 17:36:40 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 17:36:38 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu , roll WG Content-Type: multipart/alternative; boundary=Apple-Mail-195--214437088 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 21 May 2010 14:38:26 +0200 References: <38602B90-4346-455D-9405-39E529CB4CF3@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 May 2010 15:36:38.0481 (UTC) FILETIME=[672AAC10:01CAF8FB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17398.000 X-TM-AS-Result: No--34.254500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Fwd: Ticket # 25 - Tracking the MUST requirement X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 19:20:04 -0000 --Apple-Mail-195--214437088 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit To be updated, as soon as the revision -08 will be out. Thanks. JP. Begin forwarded message: > From: JP Vasseur > Date: March 30, 2010 12:21:28 AM CEDT > To: Thomas Heide Clausen > Cc: ROLL WG > Subject: Re: [Roll] Ticket # 25 - Tracking the MUST requirement > > Here you are: > > > > On Mar 30, 2010, at 12:14 AM, Thomas Heide Clausen wrote: > >> Any chance of getting that in a format that we can read without >> spending several KUSD on special-purpose software? >> >> Thanks, >> >> Thomas >> On Mar 29, 2010, at 21:31 PM, JP Vasseur wrote: >> >>> Dear WG, >>> >>> I put together a spreadsheet to track the "MUST requirements" >>> spelled out in our four requirements documents. >>> >>> To that end, I listed all MUST and used the following color code: >>> >>> GREEN: Satisfied requirement >>> >>> YELLOW: the requirement is partially satisfied and the WG thinks >>> that the requirement is not sufficiently satisfied. >>> >>> For example: >>> Support of Point-to-Point: "The routing protocol MUST provide >>> routes between arbitrary hosts within the appropriate >>> administrative domain". Strictly speaking RPL supports P2P but the >>> WG thinks that more work is required, thus the >>> Yellow color >>> >>> RED: the requirement is not satisfied (e.g. additional mechanisms >>> required) or not yet done (e.g. security) >>> >>> PINK: the requirement is partially satisfied or non satisfied but >>> the WG decided that this was acceptable. It may >>> be wise to document it. >>> >>> GREY: Evaluation is differed (not a show stopper for LC). For >>> example, it may take time to deploy a network with >>> few dozens of thousands of nodes. Note that in this case, >>> simulations may help. >>> >>> Let's continue to work on our opened tickets and update that >>> spreadsheet accordingly. >>> >>> Note that in both the YELLOW and RED cases, RPL could not be last >>> called until they turn GREEN. >>> >>> Comments very welcome of course. >>> >>> Thanks. >>> >>> JP. >>> >>> >>> _______________________________________________ >>> 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 --Apple-Mail-195--214437088 Content-Type: multipart/mixed; boundary=Apple-Mail-196--214437086 --Apple-Mail-196--214437086 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable To be updated, as soon as the = revision -08 will be = out.

Thanks.

JP.

<= div>Begin forwarded message:

From: = JP Vasseur <jpv@cisco.com>
Date: = March 30, 2010 12:21:28 AM CEDT
To: Thomas = Heide Clausen <Thomas@ThomasClausen.org><= /font>
Cc: ROLL WG <roll@ietf.org>
Subject: = Re: [Roll] Ticket # 25 - Tracking the MUST = requirement
Here = you = are:

= --Apple-Mail-196--214437086 Content-Disposition: inline; filename=RPL-MUST.pdf Content-Type: application/pdf; x-unix-mode=0644; name="RPL-MUST.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFWcty20YQvPMr5hayyoKxeOMY23FVUrHjh1I5xDksgSW5 MQjQC1Aq5uvTgwcJAqReliz5IFoiF7MzPd09o2/0kb6R75EbWLZn24JC17XiiHzHseKAjKK/KKeX r0tBSUl2/a9M8BnbcvB+fDU/3P9PRCSi5qxJsqZXl+RH9VvwTbjCs3xyROxbUejT5ZpevhWWTYIu FzT99OF3evfn50v6pL5ttVmrvJrR5b/0y+XkYxdn6FthwHEGcchxel6IR4/itIQj/CAKEGYowsAL BV7ZYeS5wo0muIDvWR5uaceW51HsWK6H6Cw7sm2HD1vg7XEUOa7v8ivfiT3h8BEiDvgY2h/hxYHl Ob0jwjiOJ+0RUcBfIX8QDw4d3+eXOJXP650RudbZKLyYHzo5OsJv73SIIrQtNxpE0V3E31+kfYXD up8dTvBDyw3OnHBbNgMvslB4NxBcDGG7HIzwLRulcs+GgVz0wujO8IITZzQJ7d4i+m9xkZkaqHep WXuCE41OOHqCE44u0t3iplRwRbsneP0T6hiB2uOHiNFbuofcipv2KSIIOO9twj0fsO+gd8c4BRr/ cEIvl90T7NHvjy4R8q+5H9sYups2N2nIhYmEOw3tyl2LDhOOZftxHPJRD+cXavgF3cckhG++F5Bj +8Ci408G5PJZVrpcaJW2lAJCOUTHTYwge9EdUd/k3tR3JjQ0BnhvGNoHaSots2xH5Y1BgiVi7yjI J8ifiL3YCsb5e1/kdHMOQUGxcxQegwDlnTxMPk7mUETQDnecwy/TfRa/zChHsPtc0nxbUVLkpcrL bXmy/OC++Cjyp0hsBEo4Acw3erFQRqVUGHr/8udhfHSD4k0eqsyj1Dqha0GQReg6p4r/h9FLnQ9D 45aBoFqQ2XOdA9MwuZ9pGIUmPIjL+dDeqDIxelPpohfffezJgT6cMICZODxq6E8+V7IaA+hMgUYI QppuMQP3idpvsopvInAhtVBedMUw4rcKERvVA/39itE6uEOKRABDhQx5nsc4aZ4HMm8d3KtTEGFX EB6o32vN4WNQ/yELPgLqBdZQLAxdE9jfNL1cKTLFttL5kjamqIqkyGq3OQPqaUqV/KpI51VBMkmK bV5Rqq50oihZSSOTShldVhpCUG6TFcmSNsW1MuCWdKmq2eQfuvwNRnWvKmdQ0TLi9xnqcTncyGFq uVs5YLB+WDnawMbl+JwpteFaNFku+6WYK5LzTBFqYVSi9BUXZo6apJTKSj53sh2oxe3JFs1g4sKr Itu+bVtsTuInBb/rwHh32tgH/ztVlnKpAF7MVJzXuayA6F0DYmhPXqT4LQ9fbTugBvPtYjbh3mjk SSL9RlUGFormO6rQT5ksK1oVm7qx0AwLSJikGR2a4WGUxs0cxfA6SHMv1/sbTTfoxgKKuSBZUaY4 DMfG5aDyaUnXK5XX8eFO6Hd4KtgBviHpkpKtMUgCzJbOSVdICSORkl2SqdmknjafqYkFtPfOuOIJ 5ofhSsTRaVzdRqog2iuNvDPxAl9zVV0r1Eaaua6MBP5WRYkSXOtqhWowpOQGn9kYLStF/Ua/E5Ba 73CsCj7EkUSb3AERTWW61jmI3QAkoJm0WMuxzznD5SOFr8cQjID3iXXM5XbQ89+3SCvPqWMuH4jM wwzYcRJZWo8C2/cipPVTK6s9+ii3m01hKpL5LkF3vqBtrpsXTCPrbQYpxc+tfonbTdQNfvd7N1Gj ZMd3sjEtlTvw78ct57arnu8eYU8kW9iHUbGf7Ntabp95WjNZJ0ySdfvRt63MdLVDTcCcMMxr/Z8C Z2YqqQmSbY9JWZKhD7XJ6RfnPpju38a3HAf91yZ62H5NiHsC4CENrQgXVhKoGyZAlyvIDetKpvOv Jcms4ABbL6dKAOgZKTsSdaveYrs6+GDd86PgE0X1gnWQbrTq62K9rluxLnlLy72+ZeuVSoADZMg4 QUWulGFPMJku2ZFdS9OipwET0MXVSEDkIPYWcl+mylpaLx7FCQBA2BrTUar7/VDqZS6zDtwz7N9o +qI2JbWLxzKAlUWv1XNzTcCTcjeineX1Fiy82Aux0GpsI1jKBtXUa+XH5xqsxx+m7kvMRWqx5cXV CmCBY2dA1Qyi1qB/lAWWbGuYdLYbWHdYgA4a6S6Xa7DTV7UrUaPHoBqvWeH1tn99nDCpDWcO2EKA Vxv6SV7z+Ne4QOY/WZaYm/Fb+MvRxxKZQ2JlqnFxbhLV+WSd6MZa3tsCn3Au2J7znzka1Aw6eQqy hqWvWy+HqSrM1+Hkfca0IPDJd0NopKM+tsT7xeYB278eB9VhGyvnA7Z5JGIdfRrT4mOvBU89SN8d 1gG9GTQp1hvYV0w2papYTkGgqcZkyhwKjLcsyiaWCBNVBQw069xUd8jAgg+D12PAwrOcOIzBDL2M 73E+TWo/XcNWAr8cOoi5npSKXPGKcV3g59iPXoDal2bLYW1ktSqfVUjd6CQ3nsEPrn6MH+9RrHjf ttTLJF48Pgg8nQdjZZRzXbsukAog00KpzjiG8Lo0OVDTNvFFJneYox+HDQMbWthmdtwAcs5Wq8Zw yaDmWLFhUSbbMYOz3cJwDQeJ7bkqX3ZOrYbWWu54LZbDEbQ8zn+9mE1Ye60+yJ/B0sNtnpLZ01DC X69Ch2m2v595GjDxbuZBYDrBRA18ULS8qC5yrMiw3TFQowv83RyExCTQWTVJS3i5/FEgBUVyUOI2 wwNITfvLlpIVlHVU5fUmLytkejGXmcwTBpdMTAH1knSFsBXcAa4yJKH/ASyNw24KZW5kc3RyZWFt CmVuZG9iago1IDAgb2JqCjIwNzgKZW5kb2JqCjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVu dCAzIDAgUiAvUmVzb3VyY2VzIDYgMCBSIC9Db250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWzAgMCA4 NDIgNTk1XQo+PgplbmRvYmoKNiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29s b3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMy4wIDEwIDAgUgovRjEuMCA4IDAg UiAvRjIuMCA5IDAgUiA+PiA+PgplbmRvYmoKMTEgMCBvYmoKPDwgL0xlbmd0aCAxMiAwIFIgL04g MyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB hZRNSBRhGMf/s40EsQbRlwjF0MEkVCYLUgLT9StTtmXVTAlinX13nRxnp5ndLUUihOiYdYwuVkSH iE7hoUOnOkQEmXWJoKNFEAVeIrb/O5O7Y1S+MDO/eZ7/+3y9wwBVj1KOY0U0YMrOu8nemHZ6dEzb /BpVqEYUXCnDczoSiQGfqZXP9Wv1LRRpWWqUsdb7NnyrdpkQUDQqd2QDPix5PODjki/knTw1ZyQb E6k02SE3uEPJTvIt8tZsiMdDnBaeAVS1U5MzHJdxIjvILUUjK2M+IOt22rTJ76U97RlT1LDfyDc5 C9q48v1A2x5g04uKbcwDHtwDdtdVbPU1wM4RYPFQxfY96c9H2fXKyxxq9sMp0Rhr+lAqfa8DNt8A fl4vlX7cLpV+3mEO1vHUMgpu0deyMOUlENQb7Gb85Br9i4OefFULsMA5jmwB+q8ANz8C+x8C2x8D iWpgqBWRy2w3uPLiIucCdOacadfMTuS1Zl0/onXwaIXWZxtNDVrKsjTf5Wmu8IRbFOkmTFkFztlf 23iPCnt4kE/2F7kkvO7frMylU12cJZrY1qe06OomN5DvZ8yePnI9r/cZt2c4YOWAme8bCjhyyrbi PBepidTY4/GTZMZXVCcfk/OQPOcVB2VM334udSJBrqU9OZnrl5pd3Ns+MzHEM5KsWDMTnfHf/MYt JGXefdTcdSz/m2dtkWcYhQUBEzbvNjQk0YsYGuHARQ4ZekwqTFqlX9BqwsPkX5UWEuVdFhW9WOGe FX/PeRS4W8Y/hVgccw3lCJr+Tv+iL+sL+l3983xtob7imXPPmsara18ZV2aW1ci4QY0yvqwpiG+w 2g56LWRpneIV9OSV9Y3h6jL2fG3Zo8kc4mp8NdSlCGVqxDjjya5l90WyxTfh51vL9q/pUft89klN JdeyunhmKfp8NlwNa/+zq2DSsqvw5I2QLjxroe5VD6p9aovaCk09prarbWoX346qA+Udw5yViQus 22X1KfZgY5reyklXZovg38Ivhv+lXmEL1zQ0+Q9NuLmMaQnfEdw2cIeU/8NfswMN3gplbmRzdHJl YW0KZW5kb2JqCjEyIDAgb2JqCjc5MgplbmRvYmoKNyAwIG9iagpbIC9JQ0NCYXNlZCAxMSAwIFIg XQplbmRvYmoKMTQgMCBvYmoKPDwgL0xlbmd0aCAxNSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngBxVnbbttGEH3XVwz6YgmwGS7vfE3QoCnSIhcHfaj7sCJX0ja8KFxKivL1Pbu8 ymIR25ATB4Fkk5Rnds6ZOXP8hd7TF/I9cgPL9mybUei6VhyR7zhWHFAl6C8q6MUrxShRZJt/KsEz tuXgfnw1P+y/YxGxqPmsWZLTy1vyI3MLXpjLPMsnh8W+FYU+3eb04jWzbGJ0u6L5h3dv6Y9PH2/p g/iyk1UuinpBt//Sr7ez912cUWBF+KWMgjjUcXoI3DkL02IO84MoQJQhCwMvZHhnh5HnMjeaIf7A iyxE6oaO5RGzXctFdL6N5/RnrbrrDIfhDDcgbDxkbjBp60960ElQcxKeY04CLyxAZD6xOGaWa05i 9uK105/EpzZvZK3rw7xQh+HFLvm2bXkBObFluzHynyrQY8Pymxrixfc8HZZj+6EVOLpACMvtwvqb 5rcbQVW5q2Wxpm1V1mVSZqZmC2IhzWkpiC8zQXVJPEnKPC9TXuPbiq8WM33HSia03FWqVrQ8ElF6 LHguE55lR8L92+ajeZHSgv6h299RfHMEj4DbSTaea4fjYwbg+nzmSmQiMbnku6yWWwS+5fVGIfwD r1K8Il3Fc0GpULiP17IsrMXMYLKtDbjzMEw+hTrngAk9BpC21BkBBsc1jqpDjAsWex1o/Nhimjuz KdDQI7F8BhoWu7Fm9cywuj9kgObDPcAoYKOWewAjJVnQrlrygpQoVFlRIepDWX1WDagMZEjtttuy qmlXACiqpru5wZNBnMaTVPrp2oCOFKCJOl4CPWA7ixnaWei2bBijB4mtpMhSYGMvE3G3uCaDonGI PeRPQxQ1lav2OQ0yXhNHTdRuqZJKLnEs4E+PveFTF7NHUqLtO6e18mIbDSiyQ915zqu1Br+3OhtN Ql4c23wOG4EQe56MU0c9cYnA32Il17uqiR/8F1sU5YT6pk5lQbyr05t3C8wedI7LFMz20fTZCUl6 JM67ZHiaVkKpu4UOrlC5VAq8BgE2Ihfqp9I7YMEUvd9Ms9ses1uPBD3Bn4ndQeRM4+V7I6Fjr8Yz X8pM1kcN77t5Bc40Lb9ru0uugB2Uou0CNxk/ioouA/vYDvXcbQ74HPZ8qYAG9KWyUJqd6DmiwlSL ad6GAXjrW2SB2YUEcv0O/w1RM7EXmX6sxFNmTNBB1htcrYyWQVpbXmGS1KJSmCADj1v99SNniAfR MTFDpkGmJdIwQp4ZZD50x2RT+h7IRrrjFFIoSVHWN4VIwHheyex4g4LwDM0Kk6SZ8+hGa7kXxUWA 5lu2E0Aytod8D2jzkZAgBZFkoCQKI5qykqc3S57xItH6iidVqdBbaY+4BViDXIw8eaoCsaJAf4Va C0MIh47v67eO6zuxx56uGlngQtpjnjSSsdH0s0bTv+pIAwa8NPRu1cDQ0Rq99lD50S4V58qIoUH1 AQzK6OXwi0ZS2okjK+500TOD2sGuMamLHgFqaO29TBvtLZTpLZTKTlNjMkP+JBt0mAQNRkKrJgoD PAPCKrESVTeS1UXGrGcFPgPET058GLO/vC8//tJtCaPTn5lF80c2umGNASa/C4ngx0GCOe7TIFHz zwKauV2vdqh6UQIWgAfmTi0BDbVLNrqtXL0tDzfb8gBspOamKzpsJK6Nh89jltdTEen6DEKrPeB7 TQ7KGAGlu0SQWDWLIWS61BjNygNlEP5FcjQIQcBG/uaykLn8BoDzVJZ0VRZXVEssXivsBFAOSq9g Wmb/7OEZBWbJaayLAVLTs9PRZe7XL+zWdoyvZxJoNtTgd2cnz9ZlBWGSj5f2TqFpKN30Kgew6Tb9 u7mw1tY1AX16MJ3gT8s68VW3HFy5DLb8wPMphrEDkXIOLVEYXQYvYX0kVWt7AXDnDRH66Ou7hUV/ am4MP1KIPMl2mi+aF2bByUVeVsfFDCN7jo6J1iqyTL+OH7vEbuLBt3JDeAUj/PQ9UzMm4wmOHOJX n2gDdm2R6O92CinPXEjR657fS16j1R8pkythjQN8gKCcPc3P+z8XK2CxnrxNqQZOTJtYEAtWCH+x 8bFgSRhO3POxZo/TBJNrLnysCE7kNCUW8A9prpdsbOaiSIFtnHOH987ZupvrJVFbkq291TGl1/Iw tfSC0INlIM012q3emMVXnsNYMjvFuEwPar2dg3piaWkFF/rOIOF7GM1N8++DU1iyXr37BF/CgBwr 9zdxTT1w9MpyTaJOLCS54XsB9w4iuJHC7V6zrdB1y50y28u64tuNRW+0UO7MpgelMVmfCBslBZFx gs9ZXqIeFcEKSiFkpmozLstI/fN0rwch5oUZjAnfNjunHo1m0hwk+I0HxFe0AgXZD+PxMm0L7nJE J1wYCgMGpx2b76MMzoko1rJohl13NRWJ1LbEU8X+RexGL4bWO3cbfxupusGe1mb5wOzWoX6maefD P3+Spu4Y3DO2xsali9Od+9SMu6+xLoMXbd+3B3yO/xPmoluZ8dS7DOMZ2F1UmRBbPZtFtYfyx6Tg K2yNL5ApdluoL8gxbJDYEjTY1l0fwJwcp/OA6TH8NWhioZwNC+XTHWW9ULqQM32Fh78RvRMVJGGO FRlO3WB5/weP1MASCmVuZHN0cmVhbQplbmRvYmoKMTUgMCBvYmoKMTk0MAplbmRvYmoKMTMgMCBv YmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDE2IDAgUiAvQ29udGVu dHMgMTQgMCBSIC9NZWRpYUJveApbMCAwIDg0MiA1OTVdID4+CmVuZG9iagoxNiAwIG9iago8PCAv UHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250 IDw8IC9GMy4wIDEwIDAgUgovRjEuMCA4IDAgUiAvRjIuMCA5IDAgUiA+PiA+PgplbmRvYmoKMTgg MCBvYmoKPDwgL0xlbmd0aCAxOSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB xVnbbttGEH3XV8yjDKQsl3c9Nk2LtkivUdCHpgVW1MpiQ5EKLzbcr++Z3eVFlJxKahzbQSQLIjmc OXPmzOEH+pU+UBiQHzlu4LqCYt93FgmFnucsIqoU/U4Fffl1LSitydW/dYpjXMfD9/FjPuz/EgmJ xJxrlu7o5ZLCRH8FL8IXgROSJxahk8QhLXf05bfCcUnQckPz3355TT++fbOk39SHNqt2qmhuaPk3 fbOc/drFGePIhOOMFjHHGQSxI7yjOPGZCKMkQpixiKMgFnjnxkngCz+Z4QaiIHEQauB6TkDC9R0f 4XmuPdcG3w6TxPND/+S74QR+PDqBj2tEM+Rs053f83DmqL+AG+ILHCxfIIn4J+bAEFXshSG/xTW9 RSBouEQcOT7yLA7PYi5zWUHIFCTwdEHwIiLkBwVxQ58LMtMF8fqCfG/Tj+QbmDAkQjfRyXdxeIDQ F6jCMUxmLt/BWTCxUYXmXvASBsFxVH4X1R80X24VVWXbZMUt7auyKdMy18i5IRHTnNKyuFOV+eNW kdw0qqIGB8n1OmuysqByQ5IKdU9rdZeliu6zZpsVVCscJ3PaZUXbqPrFzexPWv4AAPYZoDMBeE2j HNVFACJApG2UR+si0ANeQEGElg1QH9cJIjSGIxg1jJPrW/ix2ghU3Yk8i5hxbb4qHvrayPy2rJDZ HbW1WlNTIt0oBbKraFve8wdcRkV7mb5XTU0oAZepUM19Wb1/YWo60zVdKUrlXq5yxcW7oaEwF4Bs NgZZ6IhAoDcXvuf4HRv1tzLvAWZjQ7CyWNOmKncGO/kD4wn39VEMcbQZbq2D3gt9ljff/fz29Su6 mWl60911BqGerEbgRyEo1yDFdPBwE8iaThmC36tqU1Y7JDiradMWqW4EC/xGFTVHWiv0zrp2uPFn zwb7OBAXwB7lG2DvLezseRrYJ27MWJmk+QxKWmd1U2UrBnvdbgw1bbI0w4wD6rkwUtdDrtAQlGfF e9rILG8rVXObqMKUsZKbG90POJY/R32vbAXwhBnLhm8xdYAim/jJ7elWAM7rNt0CPrIhmeeASqWp s9LDWvG0rundXNV7lWb4wgPlErBKH97dMCGDrFtlQ96pZkC+FSCflVcjcQmvQiN8NoBFiSajSQUA MObVgU91FdJyt+cxZUgUTV1WjzDphEinlGBI+GIgdfruAEgMo4P0DmRk4tU411Qv13eywPAF7xRK rXmaA9IYFXoI6KCc58VJCF2EKWeE6jB/vxt00VnD52SiMHHEwfn7RH2UTsw0nCgcy+IQrZbBKUNO S/xbAx5beadoV96pNXh9NDdn54+cY2kSLA45emY0/KWpOTnSODX2/MeNcKH4s6kJutFmMjNNy0jn nSHMryu6iHxsQBggPaKG1edNKnO5yvKseRiw1Yn72VnXs5k8rpQApfSXBIhtpV4OF2IKtiLSg65b dBqyG6Yn9D1mR51eFNjhvOESe9jB+jUQ6DeBfRT9Rt+PVE3d7vdl1XSSsdZKnjCiciXrBpsNFlTT BfdbBU3Amth+MBb3l2R4ciORH5OwOZ6gdX5ftvmaZIqJaVm6ghKEimSVW+K/ahyQ+TZublvWDTRY Lw6fY0S64QioA/W9PY2a6ARqnmjzEFip+131vzjz3byG/GBTwa6GyO5ojbDo0ZOHK1IZcXUri+wf o8cwmySEzLBMFu1uhbJprVzUfOQBp2KFP9sXGc1N+AJBsAAYxlnvb25uEJwVGI+VusUCW2tJJbOC A8A+q/FUrU1gwv3L40mKV6Y9E6U5hZLp9nmBxdvWmI2s9/MIrvwJruA2LJ4GV7zQ/i9Y1ZrCsZ7W WBS1aJcpFM+uXEMGA0RwFlgSdxDDR+CBrEgrEBVXcQDWpwAUOygwZg6yPcUTj0beNvRSnpUVEI84 apWrtIHctwujlmh7WUmodgX6WqkcqzsEyCa7bSsjJbdYU7Zlzovjc5JWErOB9zG5NthY7MwtJkbW E0HLhjUZDmfMuW64eRg5xmSYWiTI9yDoLhsTJ/xHCMKx/3jdUGSZEy2CoZlGKkelLfygExLnPKfQ 6ugjiRONHZxhVk0UThiwfSlglCTB5ym8jeu48F+1IGysxKkZMvsyz1KsdyCEds90UU9GFu9CutMg 4plAFjT/Amf4QmYYTHDv5wfC/hIcwKfl3wu92qMKhGNf5NEKWI0p8LABJbBGJYtMpvWJyLwusIk2 CymM9QZ3XILlVmHRPDAvdkryJGV/o9OPJZzK169/6h3N3m2uyxz+MyavtjvgxphKaqVhVjRQe96u P5k/42rr/ZT7NO9ogvd/eYAs7eOdYV9/kpF6BIoAHnQ/UkeggGLqbM+Bj/HA5kRfPg0oDgLrpyII +ZVsJLy2tHrYd48JOmv6UEPalGNKrtiWyYfHED0w6BAaPBqvpeqLWvQxkvTFgqsx9TImJGlbFMt9 oh8Hjpo0+CQoOepQP9Fe3MkOPe67URmQdgiRzqaX1vrqyofSsL4BqRKR3O/BsKZF36sHNDkOu93C fx9Kct2042dViYjwANWk9/g20JX3stLuVjfDO+Fl2IdFF+tyvZZ2j0C0+8UiXps3LO8n93Azw0Wv 530NqfN5/zFQedhX+mcnoxY/1eF4jmkwxY9u7dPDJ8KUDeu4GGD9DiBM3nbwjkDVcekK2/n4m9j3 uAh7+ZCXco2VC/426NZ+zLMc5oLhisNG/xew666/CmVuZHN0cmVhbQplbmRvYmoKMTkgMCBvYmoK MjAyNwplbmRvYmoKMTcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3Vy Y2VzIDIwIDAgUiAvQ29udGVudHMgMTggMCBSIC9NZWRpYUJveApbMCAwIDg0MiA1OTVdID4+CmVu ZG9iagoyMCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAv Q3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMy4wIDEwIDAgUgovRjEuMCA4IDAgUiAvRjIuMCA5IDAg UiA+PiA+PgplbmRvYmoKMjIgMCBvYmoKPDwgL0xlbmd0aCAyMyAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngB1VlJc9tGFr7jV7wjWSXD2JdjEk/KmXJm4liuOYxzgMCm2DY2o0HL 9K+f7zV2AR5ttF2RDiJFkOzX/W3v4SO9po/ke+QGpuVZlk2h65pxRL7jmHFAtaD/UEHPf1E2pYos /atSvMcyHVyPn/afwzM7IjtqP8tIc/r5kvxIX4I/tmt7pk+OHftmFPp0mdPzX23TIpsu97T5849X 9PvbN5f0p/h4lHUuimZLl+/pH5fG636dUWBG+FKbgjjkdXpYuLNYphkF/BNilZZru6Hj+/zQcX0n 9mwDBQReZGKpUWg6Dn+cbbmmyx/nmy5/3P5xtXqOfh/+2IFlokQ7diIzcLpanaHWn7vKUBefgO1h IR55IYryyLcs0wvI80wrjuPIeNIpUHcK7UH5Fk7b45U5VmCbtuMb+hTcfmX/pc2Lo6CmpOYgKJO5 bMQOO6LKY50KReWekoJevfrXhb5AifRYy+ZEVZnJ9EQ7sZcF3nAjm4Ms9CW4Vh/r1rBD2tCVoOQq 09+wpb/o8p84X70H90DUSi2+6Vg2tjuOPcbUspqd3G+Jv3kvatrXZY5FJQ3XwQWisOHxb39swQMs sRDNTVl/mBaxT1KZcZ0n0VCVpB9Eo6ZVqUZm2bS2ujw2gh5cYc+Z+WnZEcgzQ9JwXhucVFmjFnzh 9WHYcC70eXuISvQFKXNraD51qAPv78cnDeoH0n5JhQgcW6HCb+tUACNGKjhxJynfhAp2FMTr4Llk iOAkZXHdnrZGEp9zWhZ7eX2sgfWk2FGeFMk1Hh8VX6pZISgXSuG/Sl9R1WVTpmWmWvxVtfgEgaOt 8XQOeKanZbfd31sU2GD5Su4A/qRpANx2NZrYJIv5K5oeeymyHYj8STLfcUmTZBlKA53xhPkOXSjT pJFlwa9rzFVZUjQ/Fl5BuKq0b9fhZX9HeIVQ3FVtYni9fTYIZAuunShOQMyJinIHmWSxOiQKzxrg ThSUHCFcRSNxAjiVTqjbT2Ek8stlLb+0r50HXnHIVtZt8G18VUmNxcgKy+lX01NmJ1KpABMC+AEm 6E/r53foz1kMb6k/XmyNxzBa8TpAEBpMqO5oxbaOHXP9MR4WiFbsS1uxHThIHwvz2vyEw9acBXnf vPz321cvWHk65cD5arpCeWR1zEBHCA+cYCcV/JWfaH/rxGt/LFIm7AXtcY34nORVJi6gPr0f3CvR rRYQh3BX2/fD9TRxdYJW5gBADihgVT02IKBNXWaDSJoEt2Sfvtwi3NGGA4hUJIpdmzT69/U6+m6j 3m1nFnysqrKGop4nVbihi1g2hczguchInbRD/hpxzQEIi/ZoA4CPct5F61WL/UYQd2EBQ6a7E+JO aEbOd4I4J2uY/y3xwE7+LtIDIKzyLk8NDgtngaukWlRWNBHMEHmFFMYKmHyA2yZIoLI8wuB2n+BG cF5OeUpk+2fnkcHA9biJQVhYkhWV9JFAO6P2fP3dZd3i+hpVfmlf03K4g5EqoP7NMT0M3pwn0P62 sltURZlpckSYe1G+YeKOOHs8dUPHAXVnoJmCfFcnnb2LQvRVnHhTq/JG/wM8fYayVcNXQpG61HCh I2lJRAf5HpljJkV5f+CIC2MR/48si/7uPHnURmAAWdo29C6yOOg3R7J84zzqIDCsQuynLTfr6FA4 GnCv3EJrlglINow75kVCTX1UHBPGLAFNTbJaJDsATakylTpGcL+mT6kNElcCNsHhAy3M5JCegLQw gpx2O74UAXxbDpNL0VpqLnOm4GipCTTnFexrQitjM9Lq3uK7iieeCjykvkW+iOEVODTAyXj+651w 8h0zDO7QXrJ0wHjgwtDi8+/Y6ds2hjmr+XMGpyFpDvCYBU2dLb8KGI3FtsFnrW7dEMbdjhHy5LPM j/nDrXm1HXY9H6pl+cHYTU5VS3xuuLGqSqUkBg1tekAL07UsLF/jOINJgqh9LOapuhKQN4OpNsaS SSu4kkFa25ra/73AtFKgD1EKYxrhhCHZUN9GO6ESNXdnmuKrjUKaiaTOToTpBodBdeBugKVAzzRG ov/Qji0KMGzThEGFdxIGGB4Jw/rrYjZ2lhi1IEzs2utZZT2DAg0AG3a4M0tOtgAhA02r6XxQ1KXU Cd64QWJ2DVnyTDzxbM/GgGeyySOMcpEozh/6i7veQnVL03oLnDUSiQojr3ebvu5+2ofg3X/AD0VQ 6PWSO0PQ+kQJA7TvhqDI0uK0NDru+Pvd7FVkZuSZKqk/iOnokiUtF00tU2pOFQ5O93EJoiN6vQ+Y OzHDERHRavHgkZ0bHfnhTPYdWJigd7u9LCpJ07Le6ZYTiy9z5O6r9wL95icM0rvGEygS5rV5Qbks MFT+ghkSgkeRnoClnajQ5un+tZ0mFUnDUyYQiOtAuNy3w+O9TJ9m8sReatx/0rww+cCe0AmaZbS3 Lr6CuGANcavpAwsz7mUYqy04RDSItGa1YRY8bxeGrmSKuCS7xmioOeRTyE0G8tec83mOcxt5DFlg TqdEfk07PQbqjEq0b3WSNqKWGILjJlF/0OfwQszNLKj+bNcHEUNxZdVoMGHsNcXgYomlatQFiSY1 320fhSDjwXe/uoNaIIhHCkO2H13v5Xw01t0Qst17IOhMUyi/DVRLejOCXv5ye0w5gc3Ey3BzB3cb btp+o6ol35pAxEL6umF+y4afTieGnWf2mniObsM3Lcuh2T4PmEF+etRIEqQ1Hn8n9KtY4AlMP/db xcKTNMGbfvywBbc0Yc2FegNaTrmMxZTrIStckMG1Jp3J6gZM7o7iZm0Y8M3abiirm/BbanomLvCM Z5ijTXfu7zatmm3wtJB5U83xc9JV06Srbmf37bAKkm70N2xf/w8ilA5ECmVuZHN0cmVhbQplbmRv YmoKMjMgMCBvYmoKMjEzNQplbmRvYmoKMjEgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAz IDAgUiAvUmVzb3VyY2VzIDI0IDAgUiAvQ29udGVudHMgMjIgMCBSIC9NZWRpYUJveApbMCAwIDg0 MiA1OTVdID4+CmVuZG9iagoyNCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29s b3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMy4wIDEwIDAgUgovRjEuMCA4IDAg UiAvRjIuMCA5IDAgUiA+PiA+PgplbmRvYmoKMjYgMCBvYmoKPDwgL0xlbmd0aCAyNyAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVjLjttGELzrK/ooAbs0h28eYyOBHTiB4yjI IZvDLDmSJiY5Mh9rr78+1XyI1GOzki0DkbCQVhKH3dNV1dXzkX6jj+R75AaW7dm2oNB1rTgi33Gs OKBS0Z9U0ItXlaCkIrt9VgmusS0Hv8ej+3D3n4hIRN1asySnl0vyo/YneBGu8CyfHBH7VhT6tMzp xU/CsknQckXz9+/e0i9//L6k9+pjo8tcFfWClv/Qj8vZb0OcInasKKIgDjlK17Ut4RxFaUUBP0IE abvCDR3f57eO6zuxJ2aIP/AiC5F6tmN5AQnbtVyE5+BHbc4r/Fw4wg+iAO9CEQZeKHiJMPKwYETj Eq4TWZ4zLOH5WGGGXeMV/CjCLd2T78YFnCCy3F0MwZDQJITZMyGIGOEPEYQ+IudCdkF8TcGQDleV s0I4qJOIY2G5Q8GcXcFe9+VBcRhGwgsBA/Jil3zb5o11YhQgjiPeka/HEfU46qDm28Crx2E5th9a gePPWhy5Q1h/0fyHBWN6ToVJVQupBYkQ/8um3gBVOpG1Il1XKltRbUhSXTZVrdLugnoja9IVyaxU Mn0kWVUm0bgkpU+63hDWoNevbt++/ZXu1cogt8Xsb1r+DKC2+3AGNU6m5HtuvNvr46T4trhbrkpK ZEG1/KBoK0uEWhBncpuYYqXXTSlrbQoyZfepKRczTn4tC/2l/cpa0Bhuz/+zeEX2zGbon8X+PsVj MIGcDKYuwWfBFOyBqZWoQzAhqIvDAor4OYIJJHLOAFOLjY2cgGMCqZRkgb+n4cLq1lWDUlU8LqBD NL9hCHJxc/lZ501O0/KctdWD0O7lFMSQHtFvdie1U4qozzWYQFtTVfo+UwgCEcgsM+BGC58VFKQy TZmoquVI8UhNMSVQSlulAC5m2jdA6oLa9XkeQyr0LtEn9whS30efRGQ/oU9L7HVpmloXa9qWpjaJ ye7m1d1iKlaMEFC4fNCJGirQCtoOg4WpKcmULLNHUlUt7zNdbaBSrZqNWnUddfIcDy2y3+kDdZp3 cggUtO267wcAxhmy0rL3Yv4eYyAQl8iKfYSBIxdxHVkJoidk5f3J+gMNoCRqCFFnRkLTa1CVzKpv OVUHkVbSqWq2W4MOMKElc5dVSOO6danrxyvJiRc4aE79Jh/IyTxXsmogF2fV/4hs/23Xzm44Ryoo 0DuEB6+5sy6j13xlcg3lMwUoOEbdCWiVzM6S3Sc7nBva4z3R4Wadv3053mhil1wPhjuYOqaTTa5t VxdGdtzkPPh8OKZd/brI4Jje1FPpuYez6BsDK8+qyaAwicn7PaNC1Z9M+QFNjMWpaqUGcAaF2Liz qklol0xTzb1EZlcySFEgUNF+dw8laAyP799FRndzZa2tG8rktjbbu8V+BZ4QqCOA9nv/jb7HRTfA 1HPoew5Q4XuMBp4q8MJjjg0b7vXD2b7z+TrlPAbFXmBTj3CqTfX60/npQX82pqphiSA73NVUCcfA HlqmD6qsdQVr02S13maK3rx7CBgYEItKVda0NV3mRK9hG/r5oWPD6ETf7KOkH2t4TosHmvqxJTD7 iqtA5bgiIuYx8MRgc6oiU+KqAiYAbgGdg0lLqa4SgyKAjChOpepmy62Ev1fFgy5NwVM2aCIfpM7a azNdfKhursRYD66BhHDcEflTgGFsUQnPVewkcVPMW8mmjaJXmLuFRWhgPL9w6oNXmvbAScrIti71 PXwVzz8rnvDIfCqu1AF91+E5v5s5dwranV1AQfenL6gmi6gq24ktpXtYOZNj12G7S1bEXCHTQlc5 rUqTYwRNUIhSZvoLtiOXhVyrtjRsAEqTZf8Ppx0F8Xhy8yxjuOzeQBnM7HaMx3eijI2jnN1UOcXY ElNWTHMesTDTqyLtRp1n7Tew9qBxfCCZNoymlZI1mxwimKska1LuM19UaQ4GbwjfVNYusRL7SoCD FIdidOyTUjD04FLm29tmewMS9x/dsvdjkGGeaA8GcATQUmg8AmjlYB+xadNOGWiTJjNrHJFkxAhd q6uJQRDFPvUIOuzeLE+sSvJeZ2xawZ+huYx5DeRBXltZJxvUgq/bz6PZpjiq4dZy+SzSNvrzZ5Gn 5tEQWN+db44sOX1cxqd3I0v6E7PvxJJIiNNgYnE9ZAQ8VKXXBeQIGkYbVi/MGSbvzgd6rO2NI09T ZiTMlQ43PBHQ3jbvKD8/Qcm+5R1lyIlJuNlP/cFfK9pwJ8i5P5Pp05yA6V+B3b0eCmVuZHN0cmVh bQplbmRvYmoKMjcgMCBvYmoKMTY3MwplbmRvYmoKMjUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1Bh cmVudCAzIDAgUiAvUmVzb3VyY2VzIDI4IDAgUiAvQ29udGVudHMgMjYgMCBSIC9NZWRpYUJveApb MCAwIDg0MiA1OTVdID4+CmVuZG9iagoyOCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQg XSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMy4wIDEwIDAgUgovRjEu MCA4IDAgUiAvRjIuMCA5IDAgUiA+PiA+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMg L01lZGlhQm94IFswIDAgODQyIDU5NV0gL0NvdW50IDUgL0tpZHMgWyAyIDAgUiAxMyAwIFIgMTcg MCBSCjIxIDAgUiAyNSAwIFIgXSA+PgplbmRvYmoKMjkgMCBvYmoKPDwgL1R5cGUgL0NhdGFsb2cg L1BhZ2VzIDMgMCBSID4+CmVuZG9iagozMCAwIG9iago8PCAvTGVuZ3RoIDMxIDAgUiAvTGVuZ3Ro MSAzOTk0MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGEvAl8VNXZP37OuTN39pk7 M5l9MnNnzSSTzEzIOiGQiyHsCMqWgCkBEXAliUoF9SUuiASVaN21gLXuvq9hNait0VetG5W21qKt lfZFi0ta2qK1lUx+33MnuPR9P/9/Jvfec/ezPOv3ec4llBBiJn1EIMq5F6/oFm7QTMaRN/ly7vrL 5L9XvncNIfRuQnSvrO5ec/GfJx24ixBDFyHa29dctGH14+dXeQmxniTkynPWnrdi1Wi1mCKkfz7u r1+LA85y8y+xfyP242svvuyKjwSzgP0nsX/8onXnrtj/5L3thGy7HfvrL15xRbe4XnqEkJvM2Jcv WXHxeZr61CzsV2K/onvdpZdp+8Xl2Mc95M7u3vO6jzXe/mPsnyDE5sQxih//MxORDGMrk2XqEcYP qn8C0RCtWhKJjuiJgRiJCdcTYiFWYite9G9rCft24hg/6iQlaslF3MRDvMRH/CRAgqSUhP7tPkLC 6hGZREiUxEicJEiSlJEUKScVJE0qSRXJkCzJkWoygdSQWlJH6kkDaSR57S3o4TkkjCUo3I7nk7E/ YDmG5Xhh1tgp7YUkVrhg7KjAW/2f4wvB8+8kO/GeE7SavIgemEUeJlPIfHI7mU7eIk+hhRvoG+iB GJlKHiUJGiaMTCMeqiX3kHfJOaSXfEiOon6zye+pA89pI91oZX7sY6xnkxvHDuIqI2kl/0WeoRfR Bah7K5nBKmkab94+Noz+SI0dGjuCvR+SD2l8bDeZgdJH6L0ysoncij68gLw+dgr1jZOV5BF6Ff0Y fdNFtmlqNf1jF5KJZD/5NZ2N0lyyQXvEsJ9chLsepB46PPbB2J/ITzWUnIcnXUtuRI33kGGWEVq1 uzDOSTKJnElW4OyV5F3qpNWCMlY2dsbYPTj6CPkbS7NXBB3qkSYzyXJyM3kAvfEOOUY+pyZaR39I n8DvF/TP2iOo22xyOdkInvgheu8R8iQ5SKtpNfMwD3rLg7FbhHPbyUN4/15ymM6mHXSYviA8pM0V WsZKxlxjfxobw/i2o4Y7yQt4x0mawzV4gxAVLtOENJdpJ4xegxauIveTw+QXqMfv0e+fky9pBX5/ YP/BNo0tGXt07EPURQ8aaiRnkaVkHVlPvk9+hFF9kbxE/kq/YgZc+ZbmZe1G7Ymx29C3SXIG6j4P Vy/As7dhlPaQIfzeQSvtVEYrGumZ9Gy6hm6nd9Ih+i59l4kswnrYJ8Kg8IbwO029VjvWhCe5Qcth UMkSshYj8B/o7dvQ3kfJy+Q16qJJWoUWvYP7v2AT2VT8HmRvsd8Lm4XtmlPaGwpHC58WvhrrB39N Bd21ozcfRy/8hbpRh3J6Ab2U/g9qPsD2CVZBEmJCnTBFWCh0CDcKtwuvCj/X9Gqe0LynnaldoX1C t6JwSeEXY7PHrkdfUHB1CJRUCU5pAP2sBjVdiPp149dLriLXkH5yC+jlNrKLPIF2P09eI78m75PP MAKERlDn8/H2i0F1m+kt+N1Dn6Qv0Jfpa/QP9Av+Y1H8UqyetbBWNo2tYZvxu50dZu+w40JQOFfY JPTht0M4ILyrIRqNZkw7Ab8Z2m3aR8Q3dCndDN1K/ZunRkYrRjtGf18gBX9hWeHOwguFP40tHtuA +idUjr+KbEEt7wENPoTf46DEA+QVyNzfqHX9G2VUC4r30hiooRKj1kKn05n4zaVn4bcIvyV0KX4r 6Eq6Fr9NtI9eS6+j19Ob6R3q72607SH6GD2A39P0Gfx+TT+gH9FP6N8YiJgJoOYEK2NZlkdLW9l0 No+djd8atg6/btbL1mOEHmF72UH2juAUEkKVsELoEe4R/kt4UXhb+KeGaSo1WU2zZrFmjeY6zVua X2iOaL7ShrVt2rXaHdoXxYBYKy4SLxDvFp8Sj4undKJuvm6l7ird27oxfQIS62do936M6Td/WfEt eqm2RHMF+wB84RW6tVvoIvSYyBYKFwm3CL/UrqYnBJm+R/uF84ULxx4UprEvhXV0MXueRoWwtklY TW4iY/QJ9gd2kv1J46IL2cc0pbmVPs3WCa1M5K/S/krj0lynPU4I+w1pYlfTYfaycJ1w3dhPSJN2 B/1Au4P9gsiao8xJPgBXb2HQduTn7Hy2jbRrarVfkfPR749pr0B/T2Y30grhbc0O8qEQY3+nJ+id kBqH6CxNnH2P5ekTkLijNERGaA/ppncQhT5L36dDhNJHhUfoHGbGaA0yC22AyjokROjbgpF08DrS JHPR+ewEWyQ8Jx4W6iiFlPgl2UgFmgOVn/4rkEvAAbezMsi0NkiTX9EJ0EZ3Qd6fLDzHJbb2iHYb 6OwBoZKcDR3Tyd4gTeCND/FrJzdA4zwDGryR5Njd5KqxProKcn8u5CcjQ/QCkqUmSEsP6rYJ+sLN opCF0LzkS8j/1yH1Z9M/k+9TGZw1TFIafuYmTRskUxfk7zb8VpFO7N1PbhP3a39F5lEPIRq5sANU /jvyPeic/8H7/aQZ9VtKHtBUotYyJHMP7ri/MIMo+N1A3qCMXI06Twafz9fMgOS9c+wCtPB86Kg5 0ImvkfPH7iKtGLuzx64b20aWjz0wdg5ZQxaMPQr5u35sD7TpFm0HW6xNa2ohY1+jL0Ef/ZZug9ye Qd6DPEpQL/kEv/9C/SdrnyX9mt9AdraM3TT2a+JCf0TRQyuhRY+Ri8mf0W8zhGFSUziT7R6bJnRD Q31Azhp7ZCxMjWTt2EWQvM+Rh3RayJ4+EtI+BNolyhmLFiotkyc1T2zKNzbU19XWTKjOZTNVlemK 8lRZMhGPRSNyOFQaDPh9Xo+7xOmwSzarxWwyGvQ6UasRGCWVbbFpXfJgsmtQk4zNmFHF92MrcGDF tw50Dco4NO271wzK/L4VOPWdKxVcufrfrlSKVypfX0kluZk0V1XKbTF58NDUmDxEl57VjvLNU2Md 8uCIWp6rlgfUsgXlSAQ3yG3etVPlQdoltw1OW7+2v61ralUl3W0ytsZazzNWVZLdRhOKJpQGPbHu 3dQzmaoF5mlr2s2I3oImDvpjU9sGfTHciscIibYVqwbnn9XeNjUQiXRUVQ7S1nNjKwdJ7IxBW1q9 hLSqrxkUWwd16mvk8wfRGrJN3l053H/TkERWdqXNq2KrVpzTPiiswDPaBu1pvHfqoGfjMe83u3i4 o7V9y7fPBoT+Nu/5Mr+4v3+LPLjrrPZv3RuI8Cd0dOAZgywxrat/Gl58E8Zp9gIZ72KbO9oH6Wa8 UObt4G0qtu68WBs/0nWBPGiInRFb239BFwbG3z9Izt4Q2eP3KwfHjhJ/m9y/sD0WGWwJxDpWTA3u LiH9Z2/Y61Nk33fPVFXuluzFbt1ttY0XzJZvF85DlxfPqSX1cl6affbX/Up5jWIzBxXQ07kyatIe Q5sa+eq8RtJ/biO6H38dFHcNrsJ4nD9oaO3ql5pwXEIT6aA2IcXk/s8Jxj828tl3j6wYPyImpM8J P8mp5GtCG4RCGye6wXR6sKKCE4iuFSOKOk5W9+uqKtcPscFYtyRjg+4j89G3Kzqasuj8SIQP77Yh hazEzmDfWe3FfZmsDOwhSjbdMci6+Jnh02dci/iZvtNnvr69KwY63qd6Dq5BffLrf5vkdratbRqk 7v+P0+cVz89eEJt91tJ2ua2/a5xmZy/8zl7xPO9Q9BvOjZdo8UZ0+KAmMSgmZsZAemcvBR0l+L82 MS3Wdn7XDLAa6jjobG0XAgwP4CUWENRHgX7PWXr6eXyn3cyfpUmIKv2vGtLpQcDqESpPG5S6ZhTX HcZIZJy9/v9uGho7we9SN9/cNt7mwab0eKuKbRyc+J3971TP3C/MXgjpxGYvXNrfb/zOuWmQe/39 02LytP6u/hVDY30rY7IU6z8otAvt/d1tkFjF4R8ae2ZbYHDaTR1oylraBCJn5AzOjK0L28erpHYu KsU7m0CmwhLgbqAAG3XubkafZT+Fbaljz+8hWs0Q++k+gRh1vLCfEp9e1D6P84wItJwY6IX0e8Sb lr5oHm0+UzrZPHe0mbSgLJ3CqjoXsUfsCawotOYpWRg+pWjJV7AohvFKRjbDUngOvpsFuu/+p4d8 r/r+YRbMQ2Nf7o0latVtVa6WDo0d31tRV0uGxl5VSlHwebHyN2L1DzPVmT1mZgxutq6pt0BTL9yr E/xWbPeUCGRIqNtnsRg1VhQUt9/vsRsv1vy352Jip/bNgeDtkQs2etPpLzpHvxixO/LZ4oq0jDbj vzqXpj2dafWP9lKhLFlXW18zwe0q0QkR4Vs7TKl3s8ZMOu/MF1Y2uMGSTf56IUbjG3y+lqam6kXn Fn5LUxsrlaaJ1WW3FN4l4KOzcN6PdpvJWUrAaO0Lrak38UaZeaOGTK+ajpiOmzRm3p6nRcHq8fgN vDGK0Ww2XCz0WRb+mPf4CKp8ptR23tSPSAu6vTpHe1Fd57crt6PeU1tVNVGtUOrKNOqQS9xarMPC wix2FfxqJ2lSYnfaH7GzG8xb7cx4t8FO7obHSIjR8Kg1Ol+kYl/Jwu/xF3aOjDY3SxjfkZaRalhQ tJO6kmVJVieRBpcoMleJJ8TYVXedN3A/nfDFlTvOjPhnXV1Yl5iz+lba/zatp2OXVEz9rHDny+88 1f/IveiHDOqwWK1DXomXayr0M7QCXm5HJZwwDA1GVEAWc6IiCmKfq11t9XcrQTuddW6P2+GSiK6u vt5RV1uWYZm7z9t+f+Gtf1y5c27EN/sq7aqK2atvK3z/14XXC/SSRNun9MKXfz3Y//C9oEFKLik8 ATznVXiyC5SyDtbhecktGDxdvsM+wUCJTqOx6R3kgEMxmzRNNlfY1ecSXEO0QjGFbcttzObz3o9q gfI75452jqBrjjny1O7w5DEcnbTHiUqhTslYVCfGol+TjXjJmh6DTmdKOEqqm2bXn7Fme+GJyuj2 +U6LocTQVFM97dLla3ajeqjfAtrH2pkHvNmiyEzbV7qqfpMWNjAjg4JAmETnQ2cM0F30MBXhxNbu J32ahUv5cI128sHKjmDNK5N2RlyRBUw7+hXzcDMez7517BhdB7vURNJKkCiiSVAMSlOdQWmpW26g Ow1PGZhhs5lzifRFD4iLt686l+BcMN4aSrLKlExmypQX1XUmq/DnCmPH2GSMq0DOVgxE+0Z4TT2G c0goUyxMKGEMFYfUMYG+w0qJLOSELqFb2CUcFUThWfqf7A3NEF23+wOVxk/yTm1uad6izaSvll7i bAlHkE0uuObTT7W3/Gux9nHeFkZmjR0XntauJRKwlGf2rNDDQBP3aLUYK3GPxeIfojbFYfCTpJJk SrIruSt5NKlJ2vlh63KACZsAYeyCDPQlnqEhdO/4mILBOnu+mMsbzpveukGZQ+OxeDQOpAAOCBN1 iWCgNBAKCKIzaUuYkl6fx8fEiMa+koRF/0paYkXJbUYpTuWVNKDHyiG5VhKfESsuXihfVahLRcU1 zlpHA+SMx20vYejjsmSD5HHXTKhvqLeDjIqExGbddNnSrvuvuu/GX6188ZqLX2rL99RfFsrk4vny pql1M2rZjuN03tlTdr5ceOqzwoE7PnzhH4Xju+9Y0fskzR+/79JcZNKCwv3q+AMnFET0mZvcpZQo 3i7vLu9Rr4Z4FS9bD4eDWac4gRFMgZTfBdtfUMt6lGMY5C+JjZ5P3DhL6N8UK7XZAMBQrUFvZgLg sH/g8pmKw2q1Kfa6nG2TbcC2y6ax+TzPsDg9Nt696ea50sgxLlEwwhDB1J4nn4+cop+n06p86el0 JmrsJW63xxWpm8zqeBdwVjpBZ0WczecUWFej26hL+BNnaH72wFdbehtDLJFgpdUb2e9ur5BDgBvh LqCNT6CNIbpWuVbnNeU93uCkWq+ClY+vbCG3u1zXrJupe0wnKvIyzVL9Ms9S74X6y+yXOe43/dB6 j/1J05PW17SveV71vut513tU/qfmnx6Xi5ZqfNqAy+f2eUq9OoPH5DWV1vqm+7Z6tss6r48xj99n 9okWwce0IpwZaA6nxjKEahgMSom5pc9ADUNCjWKWtP7tPrrT95SP+Z4RatBxN++lzBwaojcrFiL+ cZ5zuXOdc5NT4xyiOsWpoFF+Iitynyx0ybtkJvuepf8Er1moopQsB2CxiW1nzwOC+oD9hemZL/wM wJ2vKfpYc5GmO+eCtSTOXCOjnT1QeT27RW4hPL3dQJ83vGVgpLOnI32MizJ1ZBz5PJOKl+y72nez D+c7rM1bJO3VL1nBlrSntxMaAWRM0lSI1BFSV4uhEnWx+nG1KeqYLjKhvr5BeGL5qaMwbuUdl6za mUz43rrvofdzsx7+52S68qIl0/xUW/gqQc+gdz92zcOX9xx85e2BNWt+tL9wolGqhq1CZIznQYyn EVbDb5SU20JtpM2i2ATFRivM1KUDU1LBoBWpxmyyEI3ZohHNFvR7UHHo9CU6nV4vaHSiGUiihVqe pffD0jHRnYpFS0WDXhT1Wo3ZrHmWzkSP6ulqxWQw2AS6U3hKYMIQ/YfipS3qANhoFyj6qE2wiYqO 6nzWb/VyTzOXGp3N6GIUP5K4TdSSz0qQxNKINNrbbM/buZbIb8mkNZBqvGiz2UDzvVCqPb3UFbPH 7JE6WoMNFQ4eeGj0RXb5JQ8V4vTkLYV76eo+4dpTN7EHRjnQgNqshOzbAGw8QkNK64811NEROj+0 SbtJ3FR6k+bmUl0dq4ssEhbJSyIXBtdrNwS3sH5/f/BB4VHDrtjRmI3EqE2yO5wut0dfAgmNdgYV uxyBaNbIEX8gKOi8Gi2O7twryxHnM6A2r+BU0Kv0j4T9MRKBcfcMnUwCdPr+Pt0ujPMQ/VwxKjGq xLpiLOYeov88ILFdERrhD1EMsiLtkpjkiz4DeO5jVRgc64QokKCxsELXjRwDYaIMqTvCTTNIBk6J W/SZtBYdRvhOkRgVSy/tZb3ytfRadq0sgio5MYIWYecrpgs16xyrQt3a7lJtZwcUsi6i03BWFMVv 6WNVwIJcIV+psOHMwtoOarhv85Lrz7p0w8Z1mZi/LDt77uW7d2y7+Dmq0c55/EDZjhuHLjzQV9aw YEIwLUVqd2+68tdNVTqGcAkj7RiL3aBPL/CSU0rF5Yb1xu9brzW8m/g4IYoCvVrYqNno3uzRNOtT olaI+VI+UZCX66l+iLYekJM0mbRBjd+810u0XIXttVkoOlfhY6Q4TH5SoVQwpaKrYlfF0QpNha/Y 7zhFnJJTduacinPAucupc/rKv1Fkp2CcHBvXZCdV+62Z92rnSC+6UbVWxhnbBKCSM7aq6SqDCYOj NBgKMtGesCQThthKGpYCK0nEilLcmFxJgw55JYmaseKqTNVk6YprroEg6IFtaBV0p3mfazJ7rSNe X0NFVwksNqi0ooAQ7rz+kQcvjA/cuu3NNVe9uW3FT2+jti8vHH3TMX1azcwlW2+8OrlEuzZhmfej n2099+jg4zc9fs5eWnqAzii0j07dsqDrD2dkf3z3E/+CVEDfIzKlHYRdHSRh5t3NuDhTHDQcYqFS gnaQ0jBFa0p+KvyReLDosBiFPyoePQuGBJs+6C4l4W6gx4xSvY3pSbaF99Khw4eyWU5w0sjInz+j 2eKfdPWWl16SsFTnAkpAb7XZLJIxZAjPj4gum1Py2/2BQNBbKkaGxob3JOr4Zm+uvVbdpjPqdk95 8bCcLB72h4qHPerhPS51o9wlOWstNhMenrfNsk2TZobmRTpsS6RFJe2hC2xrpLWh9VKfZou137ZF 2uLYGroxfJ/tPuke+32hg7aD0k/8B0Nv2F6XXi19PfRb2xHpU9tx6Xjon7YvpX+W/jNUabDNDrAw DB50EikNhYIGqzFgcAc9Abee6QJ6l70k4LoiZJNkKRQMRu1Sib0b3hNAOesQe02xsxDMuVC49CEC UJd33BDdr5j1kk1wud16vUEfHKL/Ugw23MMesir2IZbbOy9EQ0PsM8UqK9b51hNWwfqIfGG/6mD4 /DCivX4uBLhm4gIT65MQC6PNW6xF3t/Sac1401ugd9JeIo1Qafh/r7dIV7/UrGvGvyoMQJvFP9oL KRDRqSQIkwJWVQOtoUX7QjXUTUx4bPTv50QnriwsWuSrmUzfj9Ej+c4Fox+flU9d8tFn9JV35pWF s7pEwubN/UBzzld333iWNpHQZCKVy6mFxUd/x+XxrLE/aG2gwzhlyhmGUJZmWVbIhu+03RN60Pag 44DtaYdJH6JuD8TBla4r3DcL/e4fCnf6nxSeFQxmwaphpTMQANJm9ZI9HoCZrN3PApQ+Aydw9gH5 Xm0qKNAh9sF+AHYSlYaEKfu3W3ZamGVIyCrZEgN7EtY2nSA9+ZSdhu0tdmb3KxAshmbZS23esJd5 IbrZIu/MxKpzVTs33dk7l1sFX/T2zB052YOuH+052Xnyo5aRz06ig0dOjkivqSJBdgVEMwyupCnp TogBQxUxu7DS+7RV1OixVHExUJQC6Wuu4VK4F3LAGeNGG3cPHaol6xE1MZn70444N3RrJmAUNL8I hyd/9MCW965eP3L39a9vCK8unHi28NTB/gO05Sc/2F7hCJT4TdoLCzVvHdhaePuDocLfBnoeLdn/ 6L+eOfUGXfjsDLczkOO6kHHbVMt1oRvaUFA6TAFT6Q3SHdKvJe16aX3JFulu5z2u1wKvlb4t6b12 R0lpSNC56Bb/jSGW0ovhAIlEdeGAJRLzRHzhlNVqYb6U2030weZ5DkockkN25ByKQ+sYGvv9Ad6L jpkxsLYyuaUO+k6O0e4Y16lCLOIRnU62yGOGYYw1v9QDJ9AsSWyRqB4U/fyguCO6YnwU0rCHR0Go sIphBKS/UIdF1YNcF9rzeW4WwwUJ+kM2l5QoSYZswcXU78Kq1B5eTANO3+LTA8CFcA/Ivaemjnew ajrHYnURWQNfWSdGytDvxC4RWNOxmsVxd7Bsbg1LISY46YUnXyhc/ttNi4/TCYWfn1h6aaIhcqlw 0Sa5MtFf+OmvCh/+9O2VQToNETkfnVrK+5yqff5D9Hkb/X5R6j49XeFtI4mhsS/2825I1A6NnVIc vFirNrtW7YJaJy5QnPywk0bNfBtVuyoK0AeWMfoqql4Y9U+RIK1LsVRiyWLJEDPWBiwtWJohx02T SDyemcQyQSMjLVlVeh+C0P7sM3VFs1wIDB9K8+376WH4kgGlp3v6rumHpx+drnFO3xFU6uejyBzh gCkSjYYDwUi0NhzIRKJt4cDkSJSFA8ZIzBkOBCKxRDhQFYnVhQOTIjH0QCweD0yeNMlkMrJMVVUw GNA7nFGmROkHUSpHc9Hu6K7o4ejRqBgdYrLil6Z3TR+eLsjT6fS2RLRufm1XLavdMW3F77zpudLJ Xg6jST29MB97AaN9IwkhD6GRcIi3hP9BvHWmKRdq4+4hhtiFMRVFSG4P17M1kHNFCoj8ryNFj/Kb W+hDbL3FKKdzOTY1l0vLHosxXJnLjT6XW5D0jfarp6pHn80tTHqLZ1gbOhEC5Tf0+rURn8ObSHik KatO3bGmuFMtb6Q/LJz7zZ5w4bcuK9JODZj2CtBOmLygrIsofMgjKvFElFSdL7LCvqpeHw6wSNQb DjgiUV84QCMxQzhgj8QcdsaoHq4WpxufnjOaT8Ppzhc1dOv79Ef1wpie5vTz9V16Ybl+WH9YL+g1 /DK9SoN6II37+L0oFJRS/mr9Crk70hc5GhFykfmRrogwHDkcYXxYzsRYSCd5n3f2YFSKjIqRaVHH At2Av8TXff3dnj09FuyKf+s8dKvaqYlEAn0lXPRNT526XS0X+6gc0cKn0UcyGVQCEpGoTGSqRJcg QP191i/fIz8mH5TNNDpEb1FqrKvqF7FzQgx9JESi7oaAfVLUGA5IkZgclhH4VODY/Clol1gwxgQ9 eZJexIbYS0rW/X8JLIPBqHKhUeVCo9ptxh2RFZ1FvaHKKlVknTypupIQVMc6uaDilNkLyqQeOIPf kUCu5DhxgjbhDmrujFz21Uc1ixMuVQStvmiJLJknXHfu/f+xln5fVxhINMqXCRdy8ZMA6rbh1JML wq6SzOWq3IkSIv4N/ZKjrynHbV5qJXqP1WdJ2cptFZqczjGJTsp2eNfRtd6Lsxu8d9F7s2943/Me p596LRYvFJaYm5YT6r31uelewZ0r8yZzgujV5jweIU3KsTeRNHny3jpfXa5lwrwJaxHPXu/d4Lss 10+2ejfn7iF35R4jD+d2TRic8KbnNe/whN8BHjg8YcTzifcT39EJX5B/ef6RS8ygMz3Tsktph2dx 9gLPFb5XvC/n3vG+k/vQ+2HOagsHDJGoHA74I9FMOJBSZYw+EpPCAXckFgkHyqCJvN4ooSXE6yPU 5/Vyu2tyLluS83pyWS9sC9QdUIPPwwx6PSG5XFlKn1sGrvJlM1FZjuyKDEY4FR+NiJEdygQ6gWK8 X1Mskk222dki245qlbxB21zqQPVwxxVArz2fLYC+VSNMNcNQ4t7C104YnDGv6o0BROd/XBaBN3p6 SI/qfAWyEmAOWlxJea/XnvdKjjzRe/OeobHD+z15T64kX4QMOGyQhoNGOiOUi6lviS0V86mLUFoU bCovfes0FaaNngwk5ucKqRz0WIl1NhBT+hk9RvuyS6DXEvOzo8O5JTH36Oeay0+tvzpckUjUyr3C +qWp0rLEV7/VqLun+r8+0f/VNui0sQ/HPtE+Dtoqoy8os/sd1LGdwpqbV7edUUcpo2WsytnovMJ5 N1CWMaZzRqMOjJkxEsWYBSJIwMC4xkr4uMYcDjtlLOqIljgcUfDojxRb2ZPUaDBQFvDrHQZBHQ+z Y4HdLks5SZEEaWjs6D47BgeFk/u4wOIF1dyQdpRzc0OCuVFO5XK6q/xoOSt3lvAhdUUiuSgdjkKT qppT4ndCk55QjFwqRn2pFT86zbcAJubCqD5taUCqofyRClRwkxv2xgjACdXXBi6XV4dYx4Fk0tnb 2q6kDA6foxxQSN4xj8xyLCdLHevIBY6NjvuQZvMs3e94g/6LOv7CKI8SdJAeBFPgjx8kbOzRvSFH C+PekNvSAivq+AEQlRLM8+Ke8U1A3Tvgy0O68+IRxebIO9wOIFAuLL48zIYje0x5POZwcfPl/pI8 UwAfFknxtBGqUhXpFEBUICNu/6jK0WWP/TuVJTm2GqDdwiROMfQIp6X4qWsDyXkgLE5IEydNLJ2o nXNKJ1hPk8pXWzVTT/3k9J7wVFul0wC5xMgM2P9XqPGdANmtVN/leFT3mPExSfN9ukG3hd6o07Tq LSkiuFKiwdscFrICgmmSwIFwRdAKM0v5CPtb6uRSpZSV2pslg2xgNkMYaPzM4LjJzi32uVIPolco fINOT6ABjkL7k86k1WyvAiTjraIlOpTcWpQko6WK+hhWDr2ring0WPEeG7fZ0+lrwMLQLjAMI3zd UM9tVrsKQSMVA7GeEaqn1xU2IqXteOG63z3/jwOXbL3l4r3P/3PrJbDO1xXeLrxRWAu4sZm2vrl7 5pZHC88V9u1FYhCdQs95AmmvDDgy0aRVfV9JrzhIMmjqD5rqspnLvZcFLgtelerO3BHUbfA+HX8m 9dvAb4PvxUVfmZRJJfOJfNnEVC6ztOz8su5MX8b0CqH+YHlwdvA3vt8GtI+m6Ovxdz3vxd8tO5L6 NC4GlVhpSm8NB/SRKA0HdJEYRK0rEiOlcmVFaaolNg/AVEznqoB172J6HYI8fsmf8yv+br/WPzPD hwA2PclQJTOYYTszw5nDGSFTSVWrnqrqkKqmKo3arCq/WdWDVlVHWndUZYbo9/dGuG2fPpPbDeMm wzjHdc5tBTskhaqPA+pmpEO1JWDmq8AM0FZHUYtyez9e7gl6E6lkuSdZQ+NBrMp8FTU0EYjVfMve n7lwgyKFIIBiEzXRkDwRQxgmlPvQYAPVGwOy2MsZMv3v1D/OHBPQF2pkp8w9DtBwtJ3+OJicWzv6 LHR0SQBuAv3rgV8O/PbV6t4pdWeXrr1rxvULa+azKwuX94WhoxvDlwkX8dLsPRsfPmydbjQ+0Nd+ 12yelwu+KKyDb3YhcSE3c1Qpb6PtujuoIFqRwNeuW03X0xvoALlT/zPbh8SgsSnkDCos1gt3IfJ8 WMnq3SlJIKEn9XpuxXSTPqCOZ+v1FiEdbQ47s072DQKmdc5MneahlJJiKX+zZJEtzGYJw0ueWfZ/ 8RDidtmRTnBSc8uIdHJEdbQUQ1JOBJMms9HMRC+ykxIxJoZd0SpaavCDfWxYJe3YjZSEqtCqgBkb g95ndVfRmAOrdBqdj3+Vvyp4lKc4Dp1ajjkk43Ee0uHxU85tJYR+zWzFcE9SuGH1yF39hVcKf1o9 sHDjFtqPNEgj3Qzu23hg3U23XLL/uUu3zMr/xDb4sFnWnrf3vKYpK2jgBXhxtxUuLhz6Z+FGzSfX PlgYLDy9Z+vWH9Hmvz/ct4GPA/eR14IHU6SWMWVP3MsVRUIl3y1R6ticfDn2cpUwM/5IFfOGPZnV cYRCDYlkAtmrFBmR8SvplezS8KXy+ugViX66Rb67Ctm8iaeTz1WNxV2ifD29KX592b3xh+iP2cPx p6qerzqS+0vVWJUFmbTUzxwp8Fl1U6Yptzp+ftZYAfQtSF3hgC0SJYlUgMDct0Zibu59xRRWmYjH o4wCZqLxJ5nMdBXlD+n44Hp4pXUSEim7dMKACjuTwJPB2iF6q2KbkCotDTKgVAh86B0qBtdehNPa 5tWRyFMRNg+GEYvsl+qpUt9df7heqK/Vq7ytV/tBr/K2Pup2qbztUg+6VN527ahbcZD6ijGsbxhb 6uT+WjrN+Tpb5GtsVL4ex7FGgGc78p292TS8u2YfYC5gWl4e1qSOvB9yQkWz0mpMpTrn5ZxfVR2K hRNVsWwNrQ5hlYlW1pBYPCdPqKHkNGUBagHOwrEWVccmxo7uMecp9P6ekjz44OgB6EYoTRRP7Jfy OckGNalSJOEmVzodiVARwemy/214cY1ZFAo6jpLRCeNiAVJBuxapvHU1siUkBZNz6lTxoJrw9M9H Dm1/8Anq7epfd2qSM2h48eWd1zWdyzYCVS2s/66QaHns8quHkoUrb2g3s9vpo9du2glBQUnf2B80 WsiJRrZE8TnuqKQ2amMmgdg0mCugTc+j85jB3jREpymH6xvr/UJAs9y73Lfcvzwgai1aK6kYbtJc ZrrMcpl1va071B3uznbntupvMG2xbLFeb9uSflTzaI3ksNRYai11pTWltaV1HKKr0sghOVxeXgXY bzJr0eR8uVAujHBp7aS6GZYZFQtNiy1LpMXli9PAkcMsUBOuC9Qv9C70LfR3TDin5pzac+rOqV/a YBVMpnKnKVAeM8lNE8tzTb2OXufW+N26u7P35B7NDqdeqHglPdx0oqnkTH1jgKxjgafoW0BON9Fx hE+x1N1bjajyunAgFHqmFJifUuu7twTCo9lsLTGbrWlzhVWTNKgbMUZH4QWlqoVYiiN/VAlFawHn Au8bojFFytqft7MPkO5uf8r+gV0AALvl6fCTobTEo4+4ILwzQ5/P/CUzBuWmTK9TMm9hRyAZOZOD ytNknqPTSB5wj3c8ZNuZ7oHB0XuSBw17R3vzWTUpAFKTa67xYAJHaq2gasCzp/FDtdRJpR5giapo rY/ndM5U0lRpqCHlNq7WnFjpctg1VplriMlcmS6ToORs1vKKhAOKTp8VOc2D6FWZelqqcqARtN8J o9Rwrmm1ZY10blrT2YEIRG8aCbSqJ2I2eW15Tc6Wr8HCDZ4Oao9lGEBJpKy4kbSiaj01toyApb0m xIrhibJkPFnM2VADFohcJhydT56z9sb05I9/um32X56bWBv+b7+vFHCwv33/RVff2tBUVvjxD+Yc /c+LNjR6/BEjbKL0ll3f23TW5JrZV6+++Paz7v3AoG0BIPyL227tun7phNWVof++7KaFt/2qzhfO QkWC9jHfSDOo2kd/VZqQ1s6Wli4NXUgvZBeWXhjSZyMtkXmRu7V3BR7VPhzQMVoagqCUIlF4+7ZI TOeNIfQh2fSRITasOA2YiaJ4rC0OGwlj2stT0JhDLKX49QZV0hlUoWZQJZ0h6nGH0yEuWK38DhKS QstDu0Ka0DMsRdxjnykm7lO4VQnoxtP3yqsAAkhfpNMn0fcHSQhhDlMdf8Aek60WXZxGYL8IDahj QxRTHZbTp5CzBD+DA1lUeo2jy9z341AxH4XYv0kiFdDSxZyaB2xJkzO8ZuHzsMuzoy9wI/3B5ana WbqkpJ1TeHFhvKnhq5OnDXKN2eq86BzEJdV+NY0d1e5Gv2bodQdJDu5HRbY2h9rulePqVlnoDtam xCZxjrjBpknEEmUTYhPK2mJtZQ+V6crL8mVsfu4y05W2e8ueL/syKTZbi6hUOBzwRaIVKioFYNAb icFFh65iiZTFUAFf7a/7eL+h8JHqyKkF7o2Vc49NMhj0ijmvR8KNrM/pGYCok4q9pARAlAqG6kUV lOLOH9d2ej+vsTK1pU7K0e7crtxg7mhOkwvL6nDK6nDK6nDKUYdjk5Ouc1Knqr+ciE8BYw3xNzt9 2ZPf+IHc71OHiccHgTnjDyrh9EHuWXBvcBzkmn3Wht0NeiimZCRltEeBUDDRlihLxK1yFZHsSXN5 FTUZI1KiiqRMWPHRVQ0gZLhwPgU/kh6ueujXnhhCsVz3JIFQf9tBK1F5cBy3Fn5Bj9bMT7vOGnnz 9x/l5DZA1bNqF8Z9pXO2r938y7kAjrRliURruGf0vTf/8MC913Z8zhxXn5lI1MV7R3fPe7N31mX7 j7AEMCTwV4LdJ9yH+KxIngM6q28HXHaEYTbJTDZNM03bQZEfr1msPZ+ez1ZrVmvN40Fms6AlTIsk SarV63i4Pk9aarI8ZyWwT0BauoYnNyHpoESrFXkAnac6ccxG0BCq1WgQF2P7FYOIBKM14hqB/ZRO RYjmAFI9DhANnbpf265rR4od0sjmjoyOwkwYBXuc4tjL6Yj3FhgKeshUHt0GsK9mQdEYpX+jj51T +FHhR9+jT2nXjqJfRg+wQ9zGmzk2ImwVnsK8gknCzPFYqNyiIqstQNzZIldAl0noTSZu+XGySBBz DccKTA4HW1Tj5pdg//cq+aJwUnFxEqpRr63J69StDl4OCFI24JZMDQlpyitztWbFgIealdJSvrbj FFI531ZC/CKkVmzyUq961Kte4ZUSIV1zpQaJai0jL4H4YIdzIjyUHeXd/Hb6EHD7Q+qh9PDw++n0 S9LbhzjcGlDWmYL9NcyxoJ465HC+r+VRwwGj4Eg7riZX19xAtpm21YmlDneT1NLXojEE52jniG1y W3ROk9KytVRvtOpkEp1JZxtnmmbWzW5obZo5aYlpjWmz4Xrj9SbbQvd1bhZuWd7CuvSYiticKa+q fZYGkLJpHhs+YMibU6Y8mgU/valOMs83MwWrLrMgq5v1Zo252cuBi3JTfp53uXedV8h6NyHy9h9h ROzQ4lyz0szQ7O6qvipWVYd+GxKmKXaNKTNcRau6EqTGYjbX1qLjT2EExEU1z9I1BDMm+RuteZII J/oSAwmNkjiRYH0JmpD4RYlnWStSeF2QweE8Mt/WKKFANl+tU6x5GXZyn06QdPSEjs5Hwkrr5NZL VIqDHu9NI+w3koYcwE4aUltlebA9oEDScnL0WKc00tMy0gudn7bn+TXpdLbIGXsEMzCeDu628uFS dfv0uonBmNbZ0FjfyJBTY9QjIS4qR5lYZ8rDzyl1BonDaQtbgjQam6jNB0mjvlamdbUmR1AKUmsU qyaxOcgVNZc8dNyJSlcgP47buhQII9Q7dHv7nhYHj350pkkvbN991WgpKPLoHkndHLDmG2S0nUNL Zr45qphMea+MJDAsQU7tflPeiKFswGJMGbE1YmvA1vA1lsSpkf91oJ0JcTxvpAGJTGoCA4LJntPZ kDyciewSnrGmRjVdRbMa9/CIc80ENv3meP2k5VeGyt/4bMmClkSSZZOJ7ODOjWdODDqMHptkdjV3 r65uondVzpu6uHHO9Rfbfdde0Fo99YrF8a2ro9HKpsyE2qrFA+XhM9KbC69dN7FEZ2luvHPqD2hn s6+yKz9DzQdiY1+NHUOO1C2IgcbpL4u8vzuk5TwMMmGLtCVm4lUhQS9I+CM1BILCKSRLq7x6StVU OHISKDGuN5u9HqJhBucQgmz2EsWAy0rg7SYMpkgH06noU8v76aIBqHIqomvSK2Bb5EaMC9AkHiHg EbiP38PvDWm1yQThsWhxkZdx+uXV+RK1ELnE+PPT/JDZnEyAsPBUsP4wLx0af98hbm/y5IsNUpL+ WDwg7td9EtZok62Wzno5ebmwXnODsEXzsPCEXjddR5v0JWWWKc5QyVSvx0w0ATeRkI50uibVYe2A lnVp+7RPaQXtp2Y3Id642SxZ5lu6LQMWTR9Wgxak2HEYIYfisOWwRWcB/z/dXGfpSrw4u4irgjW4 5uTsM9rZW8Tlelvsnrya1agyR8onCyZdUhZCMvUbvUHi85rMQT32wpqITH2mAPJUxIA8nlEzrnsR zu3hVN5Jezs6aH0xEb1IXbU8uq4rQ6Kk/TRqw+0lOnHzvTf/8kfbnpj/0GKb7A1WWKmzqubi/LIf /nBVXV2KfXHwr784eUdfU5Ow//4ZfinWPZoa/d2EmlefH/xJAEgEmQYamgX9EaGf79Fr6GkNwvzf CWGrWkB0J2wGXVekGw41ukQN+EYAYr69zwlLBoXXD3CdUlotQMhDgKc7W14aUaOxh3j2zG6HGkG/ tKKqlsT46HksS7Qs6FyoWaBdIC7UtQfag7o12vXaPtIX2Rd4WT4sHyUfag0NmAe62LsouDzW5e0K rvf2BvsdtzgH7APehwE8PBXbi9msP9P9zPex/ljwE/kk9YpslmOJY1t4m9wXOxHT2WX6HKYUyVjC EBmYsc5FcA500RXpizASkSKyGgTsjgx8K4pyImKJrC79AC7pz9wJgw7NOwI/m2+URkcejTRF3gyb 6TzzdjMzZyU14tYFvGqADGKy8lFi4CE4Rh6/1H+dn833051+iuxks+I4IWJGryQWE961Ymu09SC7 teh28byMzt6e0Z7OYz0qWaXTSIzrQWZMT+8xxziLGReUnlt6aanwg1JI5J4O8EZjYyPmOPNkOOB+ ENpcRBLJmw9A8h1w5rWSxGGCYUhLyMbh3VJR5NE0SKyHcruMYdqFSmsowzAHRA7KUkUZcjaEWYkj 191/nNJ9W/6runJiyG6KxSavmnTWA1tXntlQS8/Z/99U/OAItW6fm8wmXevDoVkrH/jxV60ZQFBo /9SxY/Dxb4FjUsVmj1NXMqvGf8tFxOeQGaFGdMfJjcilblVkuU2oK4xkTlGyaiTL6tU4+qVStIC9 XGjJwWeQFlDKlTX2SsMOLrwkp2KwwgIuIQkMXWUlJ0hYuJBdWSzFBIE0jIyXpGEux7idcVqAne3A XUQ2CQK/NdhdSpXSLsDzYRMeY3KrUsyt4SILNSzhWxmhZqwZl2eynM2Uq9eojcNcYDGbUeXaoXRR vPHEhDQXbe93dh5qGYFsa3mfy0+ASXBSpk+vzWKIlDOQOtaVvUpzlbZf05d9Kjuc1SnZviwjWXeF K71Iu0i/MH2nDhOvqZxtME43LjberXmkYldWN5w9kWayTOTIM6B3OENKW7M8T/6evNp4kbxR3kl2 yo/rDupeqTAl9c4y8xRHyDnVVVrmnhIMlU4N4zaTptKl9lq4klZWhgVTmJgiZqQorlEcri53n/sp txB2D7iZ+9Py+SLqujeVqeXbp6fXia2Z1k3jkScYuL2dcPz4H4zckV40GQJSUiUkKW5UQelPpjX6 skRSXy6TtAarlC4h0wptpSoauRPBc1xA4iqFI9eFT9fpgIYGrfLkIihjKGhOsVw2FlWyRxurs3PH f5yK2c9a+2bdefTL/94wDzLSn7ZQe5Ut4g5UmQonMmLzudn2tmWDFy1bM23SVy+/TKfPfeyHqqj8 6v0HpgftsZ7X6JGp3fl5a199/TcqTc+BzFwgDOKLGKXC1eM0ndK7ofPMNhAhQYQAG6sqNK2unEIo h7IZQeIiphmPDavykhcUO4/+EWIKJOw6ApATKbU4ze/mhf1crmJC1tg76h0ovP405wdNtckEEuIi FjKWp3hi29mpEjZUcvYQcl5O03Opqw8THgaJwKvAcwLUShTfqFcB1jgnYkkn6wZ1mBjWBfNxl06j u03zI80ejcBfpUPTOC8mOYWXlIRDaCcvorUgfN5abKxufshqDYe+q8bTSKtEXTtf6uxMT1Drippy ggfit9zb6esiXSXvCFqfHISxFsy7ESIM854xts6q1Ye5muC7e1OpWvXwgopMbUD0Gdqd33MvR/7+ Mr8OWeCiDvMRtK6Z4lZ2k7jF3C9tLn2QPeHd73ybvWt7TzrJ/i44HV26Ln03WrfV8ILuVdsJHbSd znI9EwycU0Rwyqx6wzQ23TAvvJAtNKzE1wC2Orf67nH+2PBj45B+v2HQ+DP2J3bUfNJYoj+sw5yh wzrWw7e87zgwPYjp/ldrSkjO7eItcCKWudy1ybXT9YFL43IFfqWhGMHDUCLYHN/j5JsjygxHnvfx OQHKaUD3JsIfgbzNTde5N7m3uwX3yZKSPp7cMqBnOf12/Qd6QdIrSHTp1g8i8UXUP251achWTldC peLIWXmupUCsklW2Cies1MprYkBfWltDrePWCxyBuaNIWIeZz/PWR2Dt8wkCnEXBbb1ICOAW9zoX LG44CTwvE+oHagbQTWMjgv60tX2fSBDr7ulQXQTcVLTLDxId3maK5c1KVd6CBTjH8J5UnpMZNlxK 7AkU9wLFc+N7xuKesXjOoO4pVkPeBTjbJ9vzFiwcZOBx3m/+Ojo6nGIRsfOMazFIA7crEVHRpaj4 Hl21asvSzVVh1+t3P/TpXw/c+8roFvqoVvKdW7/gOjbxzcsuO/eKkq1/oPTdT6nujceb2uONyjWw ieZh7sFG7U0kzfTj3J2oUjVWlcJ94yrVuw4A87CKVG8tp3quxqgDff2J4uAManXwI+OBQpErKOSv KUZ9PBHCFwGQtjJEA3scIs88HhmWhlsOAQooqiUopWHpJekV/oPRhMaOM/JBzMPh9yBLNKCUlotx PElfzkOT4iIqcg6kqm2tVuOIYlK5UT2Oar2n2thWa1XlaSUEKzs9jNcfgg7iM54CyuRt8j2ue5LC VGGqeYZvs7DZrL1XQ7NVmyID4oBup36nYYe0wz5YZZBEyKnlFcvTLKi37gvpb4vSfSHdkKBXwrHQ ztDzSMO2xxMemp4PFzhXUe6wi3qdUQKBD9Gz926H2zvEvthDK9JDVFIsqXLqsNml22w2GufEurer q1bdNjUVty0txW28Wt0q7mCkdsBKOYkvt3Zbh62HraLVV/kMJpXpxsFr7rem4euCdFUPtxmbjzqP 9apYZHMzJma0jMK/hdRUNZAjUVbiTiZcyYQ7FSRlJfEgcBc8gPugxXgLDKVvQZXIILbH6mowURQG ujrLAJpINZrg/7lqXPThYGLygtH3y1Nn+Pbsad/fc357U23IUzMrHE5mlOBnwpzRh/uilfF4aupK tnRG89afXj61qjFUF7nY6axe884ZM0B+ZFJhmvBb2OUTyUzSIdylXOtwz78reU+9QKqkZWx9xfoF jFSIGfHsbbKmpWHesnUNlye7l23XbNde57neu72uf/J1bdtn3zDvDs8d3nvmDWkOavd59nlfq31t 9vCyw8uOLjuxLOCXXTVSXUl9eJn2Ef2s+pYAcQv1kVkB4mv95nsMBqezxKAH9OBAkufv9zmgkVAY 3ouUH74FjGRq2Zl4KvF8QkgM0R3729N9cLhwqWLh1zp2Igj3fETgDgO/R93ilgiuVbwDs+gsPkdq FqY8tMyq5Kwza34JLRmiesW5Tk83Yb4EPFEgonXiPa20dUioVsy+Wcasj8739WEe1U/YL4HwGYS5 SAytVoyizodvxVRW2ub+VMhB34WwzpO5Qk4JA0ldl9ue25kTcl6uX3NmrvZydfmM0LeQLuRts4C3 UXh9n4Q3qkf4JSjwxBow2MJEOEURXRtWkIhVuz1F56W6U8OpwylNysqvxKliFg8Kf1Yc3DpNXS4v yy1Tlu1Cn2uX8VuDJnPtMuv2O6fRaSqWM61adlObu9v9FoT90NjfFDu/z23mhoFbrSNQ+J8oznta aEt1TpgvsPkCZl5KfJoSutRXWqtu8VRsT6o+Pi88zdsonL902TP0ChKhxt1bEXcsor7wLHpHQd6d PSPp3mNSuocfhg7o5dI/3SMdQxYDnFo+K0dVCqMfcRXRIo3wvEhYGb0Svx4XQ0vseyvyQYRBTyBS BLMMQdF9byU+SOBIL/douesOifP1zLLTyNHG2Uua2uJ1wVKPlwIcmFBdU11bLYhTkvOSmURFcnFi YZAGJ2Imx+y6uTLSA1pkMknbEiTzq+YGydnphTKd6p0WpIvKlgTp4iWlTQFcHphI5lTPkunsWXX1 CmuVIccna5qD9MzsWUGyoPwsmbR5WoOqu10EmlTEughbq1FS3nr+VwHG53/IqubKrkeFnBRjRgKN 1iGxLQOC2I38NlzagWk86nxxD/QOlwRAgGKxYnJFmQoGcaDIw9MtOJ7Ek+HhUNU3qHfRYlhKDUGV JeGH8SDV+B726xYuPbTruq4X01bM3RRs6e83vvTQ1OmV4Ugu2P3zSZ3rLrj/qxc2zzbZ63TLa9N5 6pq1amrt/Dkr22oKX2ZzTat+su+Jmtp7/0DPLP9Bx40vKVrR4PEbteKM7r4DJcl8iV3WaQStwdJ9 ds+5ty2ZUO/1Js4wnBuuDse+x7as37hjyRm9G3cuPePUNTXtiVx88qYZtW63Bkofs/GI8Hf4c/Vs +7huLG2E0kPqmtFuVBWh0Rvn+141hARw9EsVZkLhaDHT22vlmLM3ybVlmBN7MlJbV4bkCkzIQ1Kw +oxIlZc/o2po7F/7+FEUvlBhKxSKPIbCZ4qN316lPq+Kwg+bgmk+xIElgSWFpYzUQvHa6lQsq66e lNlLKzUcyULWODxBNV8cRDnuEarYk/TSKxOkl9TkcXiGcBG5Gj5tTbfXgq3FRXXqGm8sq8VD+SPt ZUZV/RpVlWtU1bJxHO1SD43jX97GBhpRr4yohyPqlRG05oSK/6LwN/SXyFt86mmuxKuqGhvGtbaq tMfLh0B+BK2AIwmEjCOyIOKAkm1UKuqMjV2wm20JW7KvcaBRM9g43Hi4UUiLdH5jV2M3P6Q0Ulnv LQ/ZhwRM3I1WlYfKZkWN5SFpVixSHkoOCVYlE6sry0ypDdVNpXJZPVFbCWzAbpeMPm/cMGCkg0Zq M3YbdxrfMmqMXEghEhSJZ8JV86u6qrqrNH1VA1VssIpCY1UNVx2u0lR1NTwM/xBwMwxKblnCAv12 4jtiUJj9MD4zeFw5l/iDWr2YCCSDWl+Q6vR+XSlXz+BbVUFzeBiBEu4RUjvXx0VgFixXTIgHt/GI E9xDUac6h65IHeZJnD4In5HOXXftlDO7A06rMacUJruUCUYhPDVXfcEsV35aoWlSrMRrC/tdWSt1 aG8ZXbmxbfE5yuOF55YAa+N5PdKZdOqd38vWzisEv5cJx+NOY+NiYVLRf+T4RzNWOvCLiUTZeHzm IIlDEZRyE9FhUcndElGxjIiaoBNxegUDNIgqy1E4qhI+Cu+ojITCzw9wujdYwFNFiY/CH9WrOJed Zrd39vOrvDIHRDzzIusim6CGo+vAw1342INqyap+O+dGMSo6YQ2+A6F+qFN6v+hKgvw5OpI+BJZA PD4NRqBfc4JFVnkgoq75c/bNng24gxemTCkWFF9Dg7hI4XDXLpHxlxIADFGdkzfvCyXIOclgiMcs Kj8gbQtkb1H5gbesyA8ofKHyAz+i8oPXG499iwfU4iHU/f1DLYdATqjvOCv4BuK0K94dH4jvip+I a+X4/DhT+CrOFeeECbXqtrGpuMUXSNR9fJGEb5WMz18LBnHOilrKQw6wRZlvihyKTDX7zM4BNCVP MCFS53QYB5Bhkec6eE9rHd8otpY64UKz2eKzxL1KOo+KI5ZT31Q74KXzvbTL2+0dwAT8E16td09s z4MqO/Bq8+838IkHI0UzFe4YmlbEScabhKaB1IvQ8Le+zeD8mq5VsgaPqlgILa+YOLGionnif/iq pxRaWzMBgy7kD6astER7Cz/RXFExsRAZlRfnQcj+5kV0xR2Vss8W7+YYx9i5hWl0u3Y76LacvjQu 6U0pp+oGOcN8BE/u4yJaLXBSRqFIeigcUZxFCi1St5F7TRb47wX1FhQ+U6kVhd+p1IrCEcXAbwkT sbyMU6w5hQMwoMrdgZ9LgO8OceROeudQUVRD+p0mzfQr8F4O3O+noo+meV+3NNRZ0nsgAJX0/PRA +lHro6W70qKMnb60IOHI4bTg16fK5CllodRUH2+SuMjpN1T4AnK5WYdZzFbEQ/A1VR3ebNuJ0DoH v5origON5Bkhk8anWjDCRbpV4T/Ox6DeeDg8IFObTPmM/ROyIMv84cAsP4fPiAvkPRXpX0T4qKvJ olz8fR2W5194mXsS4w9zCxqqpaWI9w6KhwL7VIob6e3AROnm8TnljvT4RxRUH0YKhqy20kTQFg7S kBWxBTX1q+jBQFH0IHj2XZKBOXI65YUbHcUI/DjlpNLNzWkQSN+ru5a1V2NmuH1FxJtxf0M/29XT Fenmgnxq9afHzojFJlh0SxJLbmU33ZWOjNMQxZf0MC8fsq9BeH6cgtJ+mLSYuKOuiykMdnA8vGd1 jSOcBtx8DfvguEolvKCk+W3JSH1ZJkzHTQR1hk9EVI2GjGoDZNycImGfFW0FFIq2Agp/VuPbKBQU NV0+I1F7WJM0evwJWOt4ESg09SwshiSpA/U56lWLob6BJH0YaFTQDKI8gBwaXIfPOfxxt1HEGKVH 0uOGxCiC1ghbITNKpUs1jJUefgWSE7YEJFIRuFBV9EFbPpxnDlGi+P+B4Q7jgGnAfJ/tXvt9jnvD O/N7jca8L+9fLi23Lw9fJK2zrwvfxwyfhkbCrM9wjfUV4RXbx+xj24j9Lw59i73F2xJulFvy02y9 xstt+iyrkOSEnMzmERGQdC5pET1bWihrYtISusT2kfS5pJ1pnxF+0fCi8X+MWo/BLYVLw+E2doZN NNltTovfXGoLWcPiAmERojId0kL7Qqfos5WWhsILmGY8AJGth7YCLVNJMJZhci25ykzNV0IMGpHD bTbj1eMWjgoMRtDpH6m2DQonVFmOwr9UWZ7J5BvHZTlsGzXsx22aQ1BCqlmjfl4HVs0iyUYZvlzg lHxhf8iXgblSFjUyQ8jIrZWyWH1ZdkpdqH4qyRITJE9cDpfIlMlh2Ic5ykowowMIrBx2Uk0Zsxkl yWtsIMQzRD9T5njNb2Iynwip6fN5jaacuc/MTpjpYfNRM+s2D/PYjsezE7kM/jDmR8C8IfFslmQk ZIvzVHHt/AztywzgY0RdjfkhesXeyMMIt4O58Z0MsDYszDOlXj7ThqNoQNsAQXDHCGucamn28dbD euOEIzXzuc9eNaVOnXPDc+sILvCOa4Fi2qi63sLPvaTTdUDX9fb28NBPL1L6+R+S4YpzMCSwTQl8 lnAKMzuwlCogvJSNz6ZA7lbexDf2vK24gdDme4jHDu/GNyu42j9Nsgi7w7bifgv/dgISevBRBZ1T 9Wu4jQXRUVsGeKQ4u5pP8v22cTXv41lmfSRJbzn74imffroymov7Jhdak4FU4U++zNxCZlrMZbJZ Zb+rwk4l7S2nun891WE2l5QihsEyE98t/ObKSNZqjMepy+mpoWsKhzsavTQet5s8kbOEM3ZOD9hj XF9RfAeZMBtkjYveWpQ1B4kHRoZqZZWYRaobR+lUqUFVqUHR2r+djop/ovoZOFI0pFB4RxUZKPx+ P9dfZu1PIB70WHTECRFhcn4dIddx8yM9gbsT4+zPrXN4DhJ009cWU5lTtZVKSlR9g2ABvi4+jt+p ioSqioRXqmj6oMDFlxokL5o+ZjO+F6Si/XBMuPnfosaOuFR5esAz7DnhETDjanhvy7RavlWa8hNr qWePZVX9fA9VPPM9XZ5uz4BnFy7UmctDullRWh4Sy2KnQ+aokk40Ehq34N3qY/hW8ddNrB0w0/lm 2mXuNg+Yd5lPmLXmPe5vGS8w5lVw7euv+vCPYqkomhrI/q6FctpAudJXO73Q0pLxW8NefwqfDtDe 8tWUxY2lqjUiKPdN5+FqPrbQI2IOWNgS4VfjesTTofqcHSoS67GrZoZ90RykzRUlPgqfqMPHjyg2 buLm0upV6eqGaaevQqF4FT+iRPhV06ZMn6JeN0UllCkqoUyZgyldbNGc0/ehUNQwKBQfgMK/FGgK XGTkj5mTVm9Pq7enGzCkSIkEETVIXJdg/21FzbNsCPIHYx+uML+7AVFEvubPaLCrz7Crz7DDhjhe fIac49dg/8XiM+QK/gzsv6eY+DN4JFLdPwUaxXNkty87oW0GN6rk6QsXKfya7CI6b9G6RZvwtZjF 4vRqb6LShOQsbTHHAx++4NFJ2P2jUGrDw6dVGie6ce32reI4qYMeQe88IpUGds19ha+ha6UZj8fT TTqtbuGixTpv9XS7SvF2WQ2kymnVFU6rx9INU9S9KerelDlo1yeqrpDldvTTl6omUQucNVD4m3q2 oaEdY/BnlV9QKHIQCl+qZ+fM6WgfZxxEN1BFvpZQc3VBY6B1VA8CKJc0Apk6aMGnKZ9HcsRx0oYl iyU3dny/34usTy+PReKvI6AEa3WHO/7iFvogIDu4z43I4kAHXGu5PIQJnKf2RRvKQ9UoKKbonPLQ 9FlRe3nIA+96XyxdHkIqmGVfbEp5aBoKyuTYorK5UxaGFk3VlzfMVfLlKT3RJaYvXsIHJlFpNpp0 okarmz4NUwY8xg5YoPhoRCQn0255UGYI0NYptobyTDremGug3Q2DDayBH3PPXTIlPmdOeO78uaxv 7sBcRuZKc9lc8PWBEnft3K72jiG2FFprk3eIrtqsmqXjVim8Ee6dHytums8sfoFQDehiuij+56oq bDwd/OsveqF3i7B6STRutlkSsWTcHEG6ly1qTXzbc4fjzj+9yNNc4I9zx/3/cN/HtQlPSIDS8Xwj R1Qlww8j5vbN0W9bsTV0/ipH1dr/V9qXgMdRXOt2dc++75pFM9Oj2TWjbUYjeWRhtYzkTQYJvMpg JG/sYBnZgImNlIXF2eQbCGuCHBIDiSGWR2C8hCCIb0IWg++7hJfwJcE3cQgkkDiEcFls+f6nZmST XO733vue7FNVXVXdVdNdderU2Sq/fJv7ii/3LNwU8ZgNLedNtztnR6oMqkByeeGaxaLobps33bS4 aFRHsr0thSV1vqae6dkdOT+ndZNW5sqIb623JmrXD9zc07Osbdv0jctlD7b5VbaovY99fqheKSww ZqZ7+N4f69LFyGtSgtnWafeqlgCcBcxexi67N3uOJsaZC9J/ApflxbO4rMBxGTGkxWVNPLTorJ4o IYV6yosGY2kYQGFSV6zaOUbQeTibraKpzTUkwD8uoz8kygqdSPxZSdCM9whBjk6C/EFB/ohgmnPZ 0px4Ts8QyUgQmcaVmctoDjkfklNKZAnVYgzj9reKvonvz5pyZnKzQ04bagDguyn6mDWW0/qzZY2x hgbOZLNh94YZ+I/kcQWZEAYB7jjCg4/LvJTLGjy0WJZ59U08zTvQVH6+NUbmO5plOo4rdBxv6Dxc EcPDszxQLYGihgfqLUFeM8gzgrwwyH8o3c8T1BAS7zxNt6TTheYKwvg/Mt1An7YVwHXTFQgDNBb6 CoOFocLOgrpOxRSeHsXVREEzUThWECcKbLAwWpgqSEGdJx2ylhlw6XQotqhGlw5ZFkWD6VC0zIBr StZ2NoaauqqFaC7P32gsGrVaLYYqT0y7U8cmdMwKQfC47iWdSkcMuEA6H4zVhtN96cH0UFo1mt6Z nkhLQtoG22FayfWY8unB5jITjpRA/y+ZcA6vT9Ko4j6pqprByZ3aPzORscGEljLpe5NTUprL/xMH DjOVRGgzbLkKU450NljPN77Sc63ssRib5k7Pdip5g6rzgptuNFpoKrrmNYH7Vl2eiW8/37O8fdv0 1hVhH+e9WXvZTds3fWY6uNoTxFybv54t3b3ATxwMEWgbupGYZ1YhKJoqVEM1CEGaUCauP1TZ19lI NdrkV9HcoUJKKE7KVPFqqipoT9vioPpIUsrXwgpb7JyShZ7KqZ6fbg7QmPKrXHzEuUzYb4KGw8KP EA8HJUBJlSpkMoW5sgRfjIjXjNWIN0Li2G7HqJs96tnvwUEN+iPBX+o1jj8Y2AJ9t2eF+zb2Rf0O 6y8D2rCSK6i4ksR4mP3Q/WO/qITZQt1MbxxobkrJYA/Qi6GoYsco7FMNqoZUO1UTKo3qLaijGTsU 0zi2OWf1A0hLmBi0mZ6J1JIeuB9ftc8UWrgvrFoIf8zPkF60oAKEz0zRInj+yu8JfikHkxOXlHvT 9mbgY5dYH2DuyuXLsCVoYUFH3JIQYWlpiGsSdqtLFoLMLzOPHimvFimn2SazgITAbaySBZ8aAa0n fD9CCTKshF4wxhpGHfQQFPsWcYvmFsMtllscN3u2eLdU62ATVLYG0lfb7MUAANoYJ/cZywIbDNGy yBb8D+7rF5bPJHmB4gDtYxKicOzWa258aeSlW67Y/rMlhWvmjn9mza1XzZf2PnTH3k+dGt39hSdu /eCmzo6Htr0w/ZtdP3j3i4PEK/tgepF0CGMtKRTFmspYS8/m2vc5Qy3RYCQWQOh1+gRZSjs5DnbK XPkeBM6HnM+BRFkjF4mKRq4spTIOlUXjJxUCuDJTjCBA6uOWln6NlnPJ9ALHwgLD6ASGhVwDkg0g 3HOcCOgTQEcX2BXI9ui53chBIXfm1FM0EHMGGpPQrdMsMxhmt6F3fNw6OY50oi+0BnAe1p/hlIT2 /TJqpTSWJNxUWNAZI/WGOkBfusNWFkeQ7QRaBPI8xrf1GN00qm81zCaVnqJtoe0S2w676vYsm53t mN2TvSR7tf3q7LBuq31r9nO63do3dR/ozY2zV+b7m69tVimzWYNOSqUdThBWvttrnCCvklEhGelN hoQu0ZFJSap6mHhST0SYO1iMPq8l1xQ27DSIg4ZRw16DZPiTLHJGXkCW+0iFFWJqUv0sO81QRwbb SLkXogkgRdLsLev1wkgYP+uGs4prmYxkwT69HQ4SMKLlhoLWrIs3J0yJxnhBm5NZgxlBXt8isyZj vUzCxsrQBaIkz5nQXevvl+J5N9E6ZYEhjUOYZFYwowe00AxuVJcRJrl1IsNtkDoi8yfmj/V+/tJN dw59Z1FLKldV7JmWfa1Jp9sWDXnjrFlvuW7J+jkXXaqsbGyIScUbXtm65trPvfz2gyNua930m5fl Q3Cv4jE2rZfW9jd6LSPT39kYbVt54eUH/9emC7046gn6mtOLVALGchAMxJcrY9mfwJAA+80NHS8Y lGAzHarspi20K+E6mhV7eE6HIPc4x6VIvM83zxY1jWBsnhWbNqixhhzRuFeT7ncYtZbyuAFpANr7 3PZ5io/Y8qCZCtQSCg3U0jgM1NIY9Fv9oeU2CRYURHTL3mRfnajAxOJbqV11qkZ/Y6Sjdlam16b4 lUhv7YLMSmufvz/UF1kFrZWNtrX+tZGNtdtsm/wjoU2Rkcxt/i9lvma9x/+10D2R+2ofyjzmecS/ p/qJzEHP9zFsX828lfkoUyvXDceHU2POe533uqbqtEvgxwqqPyFtsrKHDnitobAU9acZ/axoHL5i tRpLICCEw/BTfoXSIIThvlkchNOSvUxiOvoV7E+JJpu7zy0+637J/Rc4nOYaAe7zszNalGSDCWMN WqZpPvEt9tsdp2k8ktsAPgi9sZSzKlaVgOKkE0HcE5VZ0kXKlDT2ymJsspKcBR0t4E/SZJlZhflY g8SaOMGk/1sFZd+KsIwr/7ZI13jzi6ZzzllBl/eSOxfe9m/M9YPiYKKt8Nnk+o6hXd8cnn2ptPej y1fmquNxm7EI4vfa3nd++iaLy3J17HQD+y7W6+8/d3AKzp9oHw/Zsfg0xlaKPVUZWalajiU14Sp7 kpOnSW+YVbbzH9/9QkBQpmyRKNOkSPy5rCsR5pvzMCdikYu9FuHaMLiTXo+PWLpe+F/4rWLpTW5M jiSlZErrNUFVqOMo7XLfxh73v9GlJO8igvQculSi9LgE7t2oH4F/DjzAq0FPOaq0812sHW0TItcs Q+KPfCNKCa55FQ7Xps+Rk1DwAuvmaIXHSaJb2DhhC2fNiTmrIirWz6i0Si0bqGVhwnN8z3h7NAmB RSKU7BIMxlq7S7YxlZdcCxdtYL72w9O2FrvCAQ2DuE1TH8aJWoIdwoiwzEblnbIoyDbsEqegUq+W B9PEoiRX5mXpQ7vtBmib87EFHY+3V2NwlS3fPiZ8ugEUHpZON5F3ZdcRlZ1XhaL7Z7bf4uGtrQua Y9EVboe7rtFpnjtnOjOvxmdQm6P+cNLA3NLeF188P5ts6XalL5teuDgJ8i3m4XuqdbvOq+ZCKCas P3NC/DnGS5OquTJeknk+XvKw7xGXiYxLTRmXmjIrnOwkTZSfjICpWUZASLyr5Gg8WJu0uqQ1onJk 1Gyrml0LC794A2OsVuu7KcTWwVdlXPazQbgFEf0OaNdCXxVUUANiRKvBn+0g0g+U39GXj9peLq+l Z1l7uYg1qVPVekKOerVY26QtP8bn6FGza9SfUovqeK22K8TWhzZDOS7uMDLq4TsKNCQ0y6zWfM6v s1BSl4TeoGZZMpnP8dEC7YNyfARU1Gpo+q5eDa7v6g7bEW6FhU7R0Enrs76s6HDUK8ZiFvZNXle/ aVXiQdvdMbVBC2On9GB+KD+a11jzB5is3AGE+VPzTy1HYkfi/zv6SuyX2ddVr0dfj72ZNTo6squz 19dtz46xMXFMGnWP+kcDo9U76sbqzWSZb4DTSk21IftCzY+jumrJ43LAk6ovHcjer7/f8KB8V/Su mNGRMaeyi7K9+YH8zembs7dbHovuzb8hvV5tSuuaQsIzYoiFWQP48QdYpiQ8A+cpfsVe6w35ngmE /GE/s/llfAAq9D0DSZxfqXE4ICE2qqxJHqlD7EdCfUNtE1xb4KX6b/X5vGTO4fI00IsVf+ZgzEFK SX8hnTPJpRiHyIPzEPySS9C6bFF8Sb+vPgy9sux4kg0mh5KjSUlONibF5CEmCzkm7ytryWJykP07 11E4TfqwZyLggxcbYFtROsOQJOWoEygH0UMs/RMfM4wHXWrATi1mNrrMZuOMmXx/2U4ejHrytDlj KY9kWazyZL2sNzfDVQPH6tWpdFi22TXasB3ME01aV40pDIUobUpdTdbxHLXT7ovs4T/Svmd7z/5R CvbwMAAhY/iVim+cjYvj0rjxAfNO907/zsDO6vtr7o2O15lAIIPxwu1E4Dm5IdoQ+0L2wdiDWXhO xo9T7CnZV9Sn4JRJMRRFAKxIpkqGIrY2U4rPUKxHVpYDrCNtcPJkkSkAEQndXh75ijGQBVBwBguD IhMimKFkvc7ys+AEg54FX09Mga8nQFZ20D0noZSAataiZDOjHTM94KTiMKMdM+oA4FuMgG8K+Hbg kwK8G7Lhw0oX5Yof3Pi/oqfJ6SiY/mMJ5J6JocFRVuCi61ZxZyRx06Xzlsvhga/89JktS6+NuKvM kUj1Q2u7V6yZ/k1d3YOfarkgb7c5TNLe6RfuunpR3axUun7+uoe33x8y+Nn8L375omL3ZTvbiis2 3VdltXix5rnO/FVsVz0HD02nKzgsHoSDTJiqQO4sLjOaOAvG5HYytZMnnXwhc87oTSHxLt8eIHGy rEDlNOqyVo8LpyfgGB8oVXQcPQ3XxW8fqfBpfz1jk3eOAeurAlsJjBAekqeTmTS+7Ruco4ovUk74 kFBcVGPIyIzWAHNf5WILoZNJzSkYimjbGGBqvj1Qc3aKmq+CanSQpKyQpaOnfP1DoiznczqD1efW vwy3COg4fWz16ikblEtWc4UNfEl8VtjBmNGBTlNxgA2IYkfwfvv9vmfdz3oO+N7waceDbIcfJle9 5gHTgPnvXvAi3N4kHOO5vT6/xChwBXYxyd1Y6a3UCBt9jalAnfa8BEV8orI2uAI/E4wk/cvCm6Kp viE4AQMfGGqrVOqYq8/JRnEsCtxsTzinnMecx50a52D1HuhPljcH3OoPjt+5W30sohB8nD5Rlueh 6ATD8ilw+gxCX1IfBNV/A9dOysPbO1mHtrTmOc0FU/gopGdgcbJFr7yST0Xm2JPR0a76lbX/0jpc V5VWPTf97/NOf7d/Tjq1dl1+YJ14ZcRz1YLEhjItJYK/cRpnpMbFxsq48iQ5HxGojah0ZpRTFblA hSKSuVcAbOhOlLUzZD+v6HdwGQTcr5UV9ZAo70eReJerEDliM9tPizeuMcoWryaYtcAsBLP4KVLS 0BkEaGccxV6pTMbDeTbNy7IHVm5n9TFKaoW2bL4g6QxG2ei1QFUcTy0/0lihi6EwAuqYDysm+0EI Ej+FhpbfQAuk36HTJWQ+9mQNZchyAr19h48+JMoaQ5Tg3H+HA07Jy2Izzv1HQHx/zvzPTBGDogPD kGvRgSLEJjmgFFiSdhZyklaIiaSq2dgabpMXhBfIar/O2Uu7z0hvKJ6M6pKsUxvSdcnGeBCu3bsV pwHWU1iU6BVZDEaD0RjhxlMWHA0G/zZDbBxeYFTwEwB1OYfPDx5uHzy5i6MIJpwSDTu5MvAw7BLP l82pzlJqUJjDXgDrDcmRKy4buC+xGa25sjJIoNpqr7b6q+GrIWALwsKa9OXIjAq2pYQXaQeQayUr qZmRCBU5bSFSGZ/YAyQL0jpYSIWTluk/1924rfuCTdnq1gWss78jc11PcZV09+mfj3PbqOdH5/Z/ cZTd35kLsPjpB0f7WhaL2gtbxTjJ7TBG38YYlcXnymN0v14v+B0a7pndDspcBohQpoAON+wc33qr A7Jw1oAPUNE0aPIa9AGdXl8TwX1GF2cAu5waO98D2h0akedghss8IdNzjmbO/cfT6MP/+ii4EvRZ 9Y4lhpXeS3wSsBwcCxbgNHFKWeMuuHwuf1RfY4jYZUfMK/tkf5u+aGiD6L3ga/Mv0i3Udxm6vd2+ hf6rdF/T3a//uv+BwHjNt4XHdLv1D/se9j8W+D4MhPYb9nuf9h3yHw5M1fzc+57hPe9H/rpxPfy1 kr7ZYDOPM03lOJQux7D44/nJZDmORsux3c5jRfFVN1trtgl0+sGQepv8afVt9rEafZuu2dAMC88f aqYiv/Br7zTs8N7hk1odC7yi0+sKOYWAHBIcBnsIs+B2Jav3+2Svz9eoN7jg6jXg98f0OqT4YYsq HYgypwOEk6Dx+4yQA2GBGjDAiWAMup37DS8b1IbtehhvXKHYFE3DLt1B3YtwsLtd79viJ1cJsqDH 77M6mvX0O6GQTnEpV6DoaVNB0E9hw3SAPbvfVsNG4bSyUovi/VZnc4RQqw865eQHmdCG/7T3dR8Q q/dd/9sU3+AFqVV2VokxT/gVHitJ/wFnBZW1JT7JQTzWFNDtUAwt//Ghn2HkPeApgwyXlEBebzyN WB8DxYztAugUMMKOKwZnUSeDUAGAjqA1icgJWBqRS0lS0XY6OTsmQU4mNZA+wTsHGX8k7WxvdTLt /vkrVTojXDNlml3R6unD6emDnlTYnpPujifkaOO0RjTPClr0ViOcydtD8079WVK3NNj0uvL++MwJ 9ZOYL1npaGW+JCIhu0XMksDFIugTXp0qFQ9rrBoa6B1wfQ2DytPH8AcZ7dlZAz+DWEG7CC96qynU 8RB7JSBQ8B0o9Cb0KiHFH74Vdp7CFriWMG6BdYOx/PRsti4Sqa+jyQNsSW11rO4gxVDeGHEXuZyG KAxHPT6kUt1R8CSxybTHk3L9QP1V+qH6N+Nvpt6Pv58yUYWSs8DrvRAIN0fq69PrW4I++HiO2upV hkQwkU0UE8uqHq161PtoQmeMt8Zak73CYnaBdqFufmxe8oLUBek7taO2UfuX4nem7kyP1j9gu5sq xw/bDsYPpp6tfyH+QuqX8V+mjtWHcZYdzD5VVfq4NqlPadKFqvNt59v71Bdrl3svTu8wjtnu9O7w 7YjeGb8zMVpfdYf+9qo7EpJZ389ust1kV2FW4HvG4wamxbywVdlDNjkaCclCOhsSrAZLyBr2hULY 2t8+SUqEB85sVxT4DJThW1KvjaVTrnQ6hfEQTzbq9C4cjQAKxeeOGeIugyEO7+GNXp/L6/WlE3Ag VEXHnRrwHQ6ztzCNQuytyTCz2unKJlhAn2AdtNmwiZcFkTJxyhGqYJp6D+Os2jjOrXlEsaYUdBa2 REb5lHWDAfuqfU9OCRvSUbKhcSuBhj4f2+Vjz/he8r0GvPeVWAMmeOBp2RqHfxLGTXlgOxI/zGxQ fXNjjpsUQ8NAgimJ0YQI32JvPanfnmzQHcJE14EANIDNxEZTJ+FsEV/1Kdya2oVjYK5QAn1pNppm JGuS0wrETlPpY2lterDuLOX0NqxHNvn8b58+AVuRTZXZjSw/MrDAeU/44ZCRgKY7KUnR+RBY4xDQ Ff9XTiOkIUhnhXE8QFpT5DSHIwSemMnJfBJq+O/nSGhtunYdnSEBjMEdVBGnDGslYYsEOTamzQmZ L4GiPV4Kkl/js5GLrk6Wqop4lydLbn61z11GHoRAyriDW3c4ncATZRUqjNAKKqlcs6hUxiRmNoqF +Mi/NnuTnnb25IIQrE2fcyWLLLIiPf1i+vfTf49Pvxqc1Q6MogpVh7On/8qeuKO9ygJ7dQlSaZf7 9DvsoxbZSWdkma869Sdx4emnJXFhHsw34sEFIH/+A3DMLOmdCt1oShi8zQlVnYCHNQDTPFnntImz kNgv1IXsZVQDoQLwzBQPyrIFWk7vcHQb2Jh5zDJmvyNxR/MrxleqXk2+mtdb6yHhMcZMUEk0vp7T VrfVW1e1qOo71B22DvusREeq2NzYttDYa+u1zwstTCxO9TQrbct9y+N9bVu0I8YR24h9xDNS9VXt uG3c/qj3cCJkUVttVrs1G7aF7eFs2pCuamgz2NqW6Ve19LXN6CXG0O+t0HukH3IjPP3VJ5q9BpVQ T78hVB8MFuvr28gUiaM06Ht00C/hOG2qHNJvejiB2QmuVrK5uWCAPk0eJIhW60s04xDjQtwx5mmA olIBpKnHFNzu6wPfqCG+MToCL7NjURb1xaHSmK97J51O5vvwtrcXWEGt1sZ9Wm2sEHcVCnGTJ5ls zJtc+bwJ6nRevakqn4z7jLMaEl6DZGrWFqywZQrjSzTU02fAIm6308pcr4LhZF0oFDSYQGY+tdHD PPUwuLNMyj4GamYKW8OC4pvwHfed9Kkog1Zk32GxRchDzeyKUqE+CYwwKeRZ/rD4HKzi2sQLJiNH uVnYajAhyClQBm77Zg5kWT2z4pIJPwQimH+riZji2xuafHD+By3EI1xlkRLM6yhub/C+Bcfw9I5x ohhetANWlquRY+OXtm1vIaXV2dpxohjkKNuP4HZb+xHdES0iHXLB/IDZFXeAMqPGaMSsMpC24vtP 62EiDl4D0m+Qd2nI9d5Q9NX2DjMEUx1YxN+YxAXFihO+7dQk29R6EbRQqg3vBOexdKShAoknnNxv LcZlKy36vyhZyfD4OKIcov1mFJh5DvEoEuBNJGB/HAfgPvJHTYRCyVGO7GWyIWAu2vAC7IAqMDRs cL6J03PAKHGTE2vCC1DFoAj02BQi7LdPKk53sUXnLqbgHj0NsOs8RRBNx5WAp5hW7AB3MUeAlquo dQDdPqOgSdjlH//+mS/CKRiqwgs4EVPxhVhFQqWzNAzUOT109l5Z1JQk5MSvaXPaSgYFAbY3HYka PZ09C2oSrKUp1rRs+4mlC4rTfXVQoL/9rq66uumfxwKJVVPfXXTReUBN1VXenK3myivX+d1BICZv zQ2PTh/Y2iTFYi6cc7r6yJFL7N6kGIupXcGbzpy6Fuq4mC0m2Ly+C9yUOytFBY2aqZWEm5MsGcS+ ATQMXBIRarLzJMyXfrtf5EmRkjmezCFZ3lJAP/st/OtoOEoc3I/RSPBSlhGCLrt4CxzlC7Cq1kRv oTasLhdkFc15PniJ8Pn16iPYHRLdw8UETY0TNmiGPSMEzrwv+M6cFPwQLRtsEISTOtgePdkIWjJf TYvO5nrP+pbPqm/TiHq92qHz6fz6jMuf0MccMXi8mMVwhmlgvuNK/ZWGq3yX+9cFrszerNtq2Oq7 yb85cHN2h2GH7z7hPv29/nsyh4Vjzb/XREGXZDLZ2loD4/S6j4j8bK5C5Cd0ss/vb6w1uFAhm8lw 8j5Ti1tq/XqVQYeD1/0+UBu6aIXQT2IcKRb0NtkQLQatzVAn8xHFEBgzsNcMJ0lsOmT4C8Sm2zv0 vfoBvaTfju2tRQlmXoF1g1Ueh7xibCDLGrIdWTHryzd/m1TISH0MjspPrN504jQOFsJqerqiNoaD yTLlVZ0+BF+9ccbb2dUbizchl//xoKdzCzTbRN6RsKp+MkHOKfKKSKuFRKzEb2lltOwmkia2x11X F3ntqF2rq8mw2njKq/dNf6Fl70WzF7c2RoopQ2h+rHP6aWvEZ6vKYxQng8nu6Rz7MJ1y6I1mkOze iKXj1PW33dmVrc17rHP6x8XJcH3UZINWF8ZvGmvrtRi/bvZtpcGhU3lV46px87jl26oDKu14FTNX bTE3tfQJEEe64cy2yuK0Xqa62Pqa6phVW9nxpphU5ZGsokVtgvDgU2rWpx6E/KDRpOmyss1WNmDd iNNoG0UDuE5AlDzAi8N/en9FbHGF92y2TneIGFwxJadWP2kIGVVwCxmTVC4JPgyNosrKTJYqM7Wi 6oMcpNEMtZgBcPihK2+wHhbnCBa4AZujZCVWP46fVd9nZo1mBS6yJLO/oaqjqhd6xqZ6+PmE/0uf p+ob5WUEOu8XvEvHz5Gv+ndXnwBLnE73I2t7Cmb6SN0EYA93x/YjXvDCQez+vRL1E/oHuwx8CpBe BwXLmWOKHpheakTAlVnMSFgVuop5SHf9V/s9RVXKRclfwP+xaggnLB44s3M/vGp43ZR8Y78bSStP 7rOeI8sqWLGf4dwSFoF2ITzCtkbcDEdXAulJlxpP/UIcnH55TbszoEppJOH0A+zCq3qqbEbmm/5D TKr1RXOLpuOnXo5m5Svo2+PTm46uev3NZQPW9r9juiNDEH70yi+6ZmKyqMIpJmO41vP6VID7tJHp bmGFTfho8/TFtrazJVRKf22aIqsWkZC6hNvAtr9I/I6wFFCPvOsRww2A8C9ikTxQCpDcCycB8LKI s7cFYS1gpfpHgk29XFiEOEqAe/Kq3wlpbVCoUf/ozO+Rt0A1TGlhAepFkR5F+RxcG6XnoNH3JWGh SjjzEeJ5eF4X4sV4Ri/S5wHMaLtdLJ5Zh7Qd6fNgGWdH2gToxn0fIO5CfbMUFNaj3IVrEWDH882I AwATnom5A1vJduGA8CFOFbiVvchOiSlxrXhKul61XHVc/YhmvfYx3eV62TDHcMx4qenz5scsLdZm 6/v2BY4fOm9w3ej6o+cNrwHsmm9V3x18Ra6JHIp6YrMS1ycvTT+fuTH7eL2jQWlcmTuUf70wq+VY UZzd1z5x3nfRKn27NuEdQcLxwPD+ia1Xg7Ac4qWfWJ3Io1ePA8Eq30UDYbKwfNUFnau6Mkuvum7D 8IUbbrp443Vrru9bcsFS1KTa+DsTEdaXU/8UtuFaQisG2NWZoJtmE+x4tlNwwat8FZ7tE2LYhiWF jJBFLxqFJvj1hFtKoSC0CK3CLKFT6BK6hXnCfGEB/EIsEnqExcIFwoXwWNInXCRcLCwRlgrL0PsV wkqhX1glXCJcCleswiFh6Zkp6T8mu7tzygHEmXoel1Lp3EEqKPmrc89I/yE+jqah1yW9VvIEeMlv SnPnVhIts8qJydq63GswtP6N8BeAKP1Geg0O5vldcAWVO9lpRgaTboW/EgavX7ukX+ME61/jzSjS q5OxRG78WelnKP+J9GO8I7rtxyWzPYcH/kh6Gu8iLO2XnqqUPDVpseeEzmEMDyZMITwGOA44CVAJ G6VHhRHAGGAvQCVYEYYBDYBeypH2SHvQz92434qwAbARMAZQCUul7yD/Ggqlx6SrcWRFWPoioW/E X5Du4vG3EPtx/TDyQ4i/gWuKxyvXDyKm8gcq+ffj2oPr+yrxvciHDoh0D64p/mrl+kZpC79vcyXe JQ2XQmFbZwjlMqARICF1N1J349XdjSsBIZM+K13Le7APcQ5PvK4c40VuL0Wi/Bttn6zy5XbhlW7H q9+ON7cdb247ae1J22bqbCvXqZO2oc421NmGOtvwVhqlYbQ3TEMZoQ0gAyS892G8d8qfQDgFOAaQ hM8h3AnYRVfSTXiPafRqh3R1KRXGYLtisqjkOg5Ll+NVK9Ll4A/mxs5d6Q00EC+f1FsqsZXqbuB1 N0zqTZS7YdIfLMeodU2nRVonfAogQuFwnRADNAO6ACppXSnWED4kXShcpxMUS3hEHJFGVCNqVWMX czwLJcU+oOUwHATUCe2okA4PtLPWQf2QflQv0eErjXpF36dXb5RGpDFJogNbOqReaUBSE82ubcsT zTRf05bfadxlnDBOGY8Z1ROaKc0xzXHNSY1a5ifY92kGNUOaUc1O2DzryXOOOGgcMo4aJRukHY1G xdhnVIe1bFfnbdJa/EwBoQ0wBNgJUOEdDyBfli4DDOBrDOC1XYZ8AaGAKxvgGNLHEatxZUU9K+pZ kWtFrhW5AkIq6QMMAoYAVAoDbIRUIgMaAccBJwEaQBKlFuRaBBH5FuQjBViEKzOuzLgyo9Yx8RR6 aEMoA/oAEs87jhRGDcKZssZK+SBijUDlJwHQRkFIZQpAgnXEmuRUmk3QKUdsZ5op7R2dOaUGAZwp DUQH4gOpgd2qjdGN8Y2pjbtVvdHeeG+qd7eqI9oR70h17FZBhh1vSDXsVoVxiEI4Fd6tGlu8d/Gz i19arBpYvHHxyGIJdiJTk6VMI/Z3iGviFD9V8vlzrdbO2eJe/JwBhOOA1wASnKvvFRoAHYCNAJW4 F2FYfAK5TyD3CaEXMABQ444ncL8VIZVTGeWPA9Q89RpS4j+US/jhj5fa8r2di4ByBwDjADgpRNgB oNrl1F6eP4HwOM/vRUj1dwGol4+fvQenJkirqB8Iw4AOwABgCKAWXpJWCK8B8GSEYcAQYC9AJa3C vxXSCvEJ/HtcfBxuxMxN7rCA0zAFMB90tk6baMIYMLPHeHgfD3fwsIOHMcWyyPzeIvP3F5lvX2RO IgFX8p244W4eRhRjp/nJTnNvpzndacbTqoQIyAY4iEWooZD9iYcX8jCruCLmDyLmv0XMf42Yvx4x b4qYz4vQfTjuF3e4eGikkN3Dw0U8TCjGsPmHYfOKsLk1bO40s4cY+gDnMRSGeBigkMG/RpdV0B9m 72AxNYus1J4OHxAFHrEzpfbO8AE2XWqfj+h0qf0hRB+W2u8Kf499APkdljT2Xil2ItzpZu+yhSq6 /lsl/isOE9+D65OIr0D8iNDO4oi/VWr/NNX/Ju5/ANcPCzU6uu8bQh+/fxxuySn/65X7vlbKrkWr D5ayW9HqA2D6Uu17S9kTyL2rlN2B6Cul7LWIxkpx6uDVpfbacKedwXW0SHXXQSxMPVlcaRFn0wnX 4np++ebuUpbu6qIGcBx1KdqEKEm9/B6LCn28uXApyn9kUIjyzsEGgXc6IMR5bGFW3nmzUMNjXSn6 aTxF82T8RPg/2w/TDxf+zqylh8K/+x5+33Jc/pYtLO0J/9tBel2l8EvZAyy+P/xi9HD4X2MH2PJS eCp7QIeCZ7MHRPZUeB9e8gTqimx/eG/2ivATUV66O4pSfOrx9rrwg9FV4fvjuC6FP539HnVDuA6/ eDmK+7Nzwovb94TngUeGYqUdjSmGcFv0hnAR2bMOsIWTe8JNsQPUlUY8Y8/+cC1aTIBvjq4saz0k FsA326JktZu1a7XLtRdpZ2vz2jq4+gtqq7UunUNn01l0Jni91sELH2RoOkHnIuZNhuhFlwYOBMC1 A9pmgoqnbUCNDBOQQmycdCLmDiS+PWLPkrlswtEj9CydO9Ga6TmgPXPxxCwo3+v6Llm5j7Ev9+Nq QrzzABOWrjzAzlDWbYEJBx3GwFjDbV+CygRj2277EgS7PRNT64SetfLEe0vwOwwXrZpQR+d6Bc+N MBN3zLEX53V9QjDIMwe7PsZKwkb+Y3/e4MQ9PUtWTnwn2D+Ro8SZYH/PxPwlMrZo4iZxY3fXQXGI ov6VB9kt4qbuiymf3dLVf7YanJ8MoRp2Coio2qRQQ9WEGjbJqy3mT8Mwrenu2leDgCo9zxZSJQyf 53mlK3gljPFN9Kw+ilBNDAkx/qyYGKJqGA/lh1k//jCTwKz8YVaTwB9WTZX2xeNoL4ugf+W+1jgq 7Iu38uI954qjvPgg6xeowkEhzvp5O4y3U35EqlwHo6BSR9Shzsde4v9/csPc/4dnsMk1v1q/rntD tHsw2r0BMDjxhRuv9E6MrpXlfet/RQXyhJQYXLvuSorXbJj4VXRD18T6aJe8bw2/75+K11HxmmjX PmFd99KV+9YpG7pKa5Q13dE1Xf2Tj4yc3/MPbe0429b5I5/Q1gg97Hxq6xF+3z+11UPFj1BbPdRW D7X1iPIIb6vn4rmsp2/lPp0wl9TVeDwpGg2YD4OBSP9cj21oDp8csyPeWwOHVAKWLWOmf8IUnTth BtC8qeus66QizE4qsiDbWiny3jo7EjjEHqsU2ZBtj87FfszbfVXX2f/Dw8ObCbZsySDcvIUKkcCk jcBiZt5Fq1ZOtE+0d08og139nAe7pfJ3/krF9mz7S+3ixvaR9rH28fa97eotW2BEozierXmpRhyo 2VgzUjNWM16zt0ZDBZeu3K+0j9f8pUbagtHENuOvm5pC04jxny43b0FnhocFNDIMyGSotcwWeGPr rBHWgdploMzrYLVeJ0QBecASgFr4AcJ/B/wO8DeASvgswrsA3wRMUo5UJ9V1e6/qohb7+aFXXik3 2VjIQUKUm1xzeTlesqocd19Yjts7c1DLzJU68oZOKwhvJhxC+BPAq4A/Aj4EqKWclOMPR5/pr39Y GIa8fcsW4ldvpmA4s5kR95rR6948DE42AQoYvgCJ5vnrxXXlT2DDWwS8CnwQRKjE84fpNrSBe2f+ hP8CUm2FjwplbmRzdHJlYW0KZW5kb2JqCjMxIDAgb2JqCjI5MzIzCmVuZG9iagozMiAwIG9iago8 PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA4OTEgL0NhcEhlaWdodCA2NzAgL0Rlc2Nl bnQgLTIxNiAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstNTY4IC0zMDcgMjAyOSAxMDA2XSAvRm9udE5h bWUgL1ZaTUFaRCtUaW1lc05ld1JvbWFuUFNNVCAvSXRhbGljQW5nbGUKMCAvU3RlbVYgMCAvTGVh ZGluZyA0MiAvTWF4V2lkdGggMjAwMCAvWEhlaWdodCA0NTQgL0ZvbnRGaWxlMiAzMCAwIFIgPj4K ZW5kb2JqCjMzIDAgb2JqClsgMjUwIDAgNDA4IDAgMCAwIDAgMTgwIDMzMyAzMzMgMCAwIDI1MCAz MzMgMjUwIDI3OCA1MDAgNTAwIDUwMCAwIDUwMCA1MDAKNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg NzIyIDAgNjY3IDcyMiAwIDAgMCA3MjIgMzMzIDAgMCA2MTEgODg5IDcyMiA3MjIgNTU2CjcyMiA2 NjcgNTU2IDYxMSA3MjIgMCAwIDAgMCAwIDAgMCAwIDQ2OSAwIDAgNDQ0IDUwMCA0NDQgNTAwIDQ0 NCAzMzMgNTAwIDUwMAoyNzggMjc4IDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMgMzg5 IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwIDQ0NCBdCmVuZG9iagoxMCAwIG9iago8PCAvVHlwZSAv Rm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9WWk1BWkQrVGltZXNOZXdSb21hblBT TVQgL0ZvbnREZXNjcmlwdG9yCjMyIDAgUiAvV2lkdGhzIDMzIDAgUiAvRmlyc3RDaGFyIDMyIC9M YXN0Q2hhciAxMjIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nCj4+CmVuZG9iagozNCAwIG9i ago8PCAvTGVuZ3RoIDM1IDAgUiAvTGVuZ3RoMSAxMDE0NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAGtegl4FFW66Dmntt7SXdVbOukk1Z3urJ3QWchGAimyYQhISAImgUgHkhCQpWUH wUSIgAFRwpZxGZcR0fjdsSMKiSLGucs4jjiiI+NzG72DOjri1RGd+QZSef+phM07773vft+r6nPq bHXO///nX081wgghE+pGDFKWrGwN489IMrS8Aen1JRvWeeZ7OzIRwv2Q/toRXroyve2h0wgxexHi 6peu2NyhyPFbENJ9glDMUGd7a9uPv7sMfYkwHuV3QoO0wPg21N+Cur9z5bpNbyLbWqhfhHr/itVL Wrd1bHgPIR+8g25e2bopTB4iK6D+IdQ9q1pXti9p/O5bqF+GelJ49dp1LMsRmMoP9VXhNe3hj+/4 6CzUDwJMemjDcNPLhHgEcCIPap5o0Zq1jACu1y72WvH/WOJgNgHpoJ+uceUyICOsE4XM0GBBIpKQ 9UrXT542ZEcO5ETRyIVioC9W63ejOBSPEpAMUHpRIvIhihW9khDi7cgAND4LvRP5eNd4zi6B0XCN farlH10pq21jP9Dy/4+LokvT/+TCZ0na/2T8PxuL78M7cTduwBvxSrweL8MKXoKbIN8BtdXol9o7 R9GX2INjsBlj7MMSFtAlnITjsQ2zyAD1r2EU5TGEHtbyi3gK+p5o1EJ7oOUV9Ht0Hl1AKjYDn5xG S+EeQI+hRtSIE3AKLsI3oW9g9jgY+wAaRMMw5jV45wP0OfoW63Az3oB78UESRWaQZhjnwuX4HjKb XGL9SMAbiRUvZV7EFzGPHdiPXgR5ep+JjP0ZP4o+YTLJcbQJzULv4MlYYY4y6YxMzpKjCClTGgoL 8vMm5+ZkZwUnZWYE0tNSU5KT/L5Er0dOiI9zx8a4op0Ou80qiRZzlMlo0OsEnmMZglEGjrjKGwdj hIDb6/U2ZU7UY2+sR5gk8a/eCLLeMMh946DBuJ/U439ST7havzmC7JEqX3kFnXgQVX0eQbYItkcQ XQXbZsNKE5BUti33VS6LxJS3hULwRoVP9ESqvg1OgKIBPGg0lPvK2w2ZGWjQYISiEUowNjyIq6Zh rUCqKqcMEqSLysyIWAMRklRJ0/KIsicEBV8FoA49tms9Q2Mje6/vQvDa+CAEw7QSjvDlEUFb17Ms orRG0B7PYMZI794hES0OBUxtvrbWhY0RphWIOoiYpMrOBqjBypBCnZ4IC+tqmRtaPJWdnl6o02Eh yH0V8NY/bYdmfXnjLu+IO2KFZ2VECkRmwJsztpx3M72VrmUeWu3t3eWJPDq38fpeLx3T1NTkyszw 9Fb6YKGKzIzK5WVAaVcwM4OSAF8hTVtoOYVleSuFs3K5p3dPuwbrXg02bWhlJ2xM6/9rVG9vZZuv sq21jS4Ds5dHlAbtgRqaKTk8lUC6iqaJpokB0MNqPaGKJqA1BaymrrEceit9rRXAg5RPr7aEJlqg ofJKp4fCWR1RQhHPEk8E1TX64OVCmrUXot4lhZSPYRqcmVFTe+2tCJck+jy9P6AIDvkufE0hvtbS OtHCJ4k/INpZ5asK9fZW+TxVvaHe1qGx7sU+j+jrHayp6Q1XhmDV2sYIhvYX97gjVXubImKoE08B 2lMOqKprLHV7JcBjvFp7pYqApYCxgIUBHaAC/KonHrAXqKHR6ymPoHmNTW4gZCMtN0B5/EkZCRi3 EPZ4gmyURu0UWViIlieKXi/lzj1DCloM+x7pnts4Xvegxe7nkBIMwH6EaM/IlR7HPNrTfaXn6ush H2zO85qpdER0yVd/FtFpq+ycEsHO/0t3+3h/xFbeyLgJZXgoETdDS4YASHpJJDoA5dRAL2zLW76I GIhwjSPukiaPKIEGoLtX76uZ29zoqey9ygXjLROYUj4AVve1dvZOiBhlelAFZYM+vHvuoIJ31zc3 Dotg8Xc3ND5HMCkPlTU1gesCuhGB8ebBQYCH/SRPWERT8MxHZ7QsO8sreaUkyDCM+kc3hy7RJ4IC vTB6VW1jjoM9dqASJWMOriE1/BxhEV4krMaryWp+tdCFu0gX3yWYBYTdOgulomWEfcEpXryQG2zJ RaWl2Vm4BXuTiSRaC7wOMxZ44rBboxNwNHNc3TUyPDyCN889UFpSUz2t5Eit2vYp/hC74f7w0/jq 4a0b1Y+feEb9auuGV2dQeJ4EePqvwFNBFEaxVdhrmVpbiISYkC1kD5MwE7aF7WYrYt2QMMsaR9CJ aPHHG+ARieDNm4YL8q15k0nKJJyS53Vamf7hEXVXbX/xtOqaktIDc/HmkWFSon6m+j+NnzGycSt2 PvMETty4dbg6/lOV+isY3aGeYn8N8DAoX7EwCON/JYydEAb8NDI09mfFrBcLkItmdDcIUCQYCKDS YHbWLm5SYNe2f9NjL2Z/ffkL9Qzj5O1/f0popCPBV0J8AnhAAnhCv1TqeKLXG3QE3wUNegPDbuc4 voAvFGr4CmEB3yCs5BcLd/K3CwZEdIQ5EDZgAzLoMQsWcguPeYbDhGF5Qac36DkD4sCNHBr7o2I1 iAWcFzJkMWFkkk2YC7ZIuS0AYos1uggFS+kj2HKhqKi8oVHRz0azuW1oG8e2NOGWXeLoyMiIlutG oPv5Uv1sPUEtTWmY8TJe7DUSPkFdu3T0vaXqNpKMXwycPIkz1Xe4s5dXEufoV4AmUA38VG4I8HSA /5eLmpXiGnsjaXAsI22OsCkctcans1kzDqIEMYGEEp5NIAkJQvwBHZN5QHDeac2wWISkbWgoLyGj S3hhsvjjaA6wnbUoaC26gIIXSmmx5XaAPjurBdt5wYx9wOk5TuA9B1QdCRhPTobND2ApNye/YBq2 3Vjlhm6Z1fjO46MbSNnzx+rm1a/p7HtGtScF07fd7i9Z0J002XNrQVnmz+c3xD2+t7gkE7+2YqCw rJA760oL7G9ZcXSSLv4E/l3STKvIqP/OS9HVo2/PmG2LIuq9JCamnuKP0dKxP3GruG8A953DKDDW czxKLHAMjT+lobFfKfP0poLgNMh08a54H5PMpumC+mC8z9dEmthbDE1x8/3rmS16S9BWaltt67Kx NlvsfhPryczKDGWGM9nMzOT9yGbLHMpDeXPyFuUxnm38yclAphbxxxxUSoVCy4BEgQAOBLhEf0oy yZtsLcj35wKpnM5oyZecnJKc7EvkBZ532GkbJVd+fkGuxNM2ZtGT6hft7auXt7dieeDWI0r5yrSM uHn5Bd3Vc/umFVfPKZl6uLrqninZDe7Uwo7C6u74xa2tOPH0IPYsXbLCIdmCdvWIq8zjycgtLjq1 c++p/IJguj++zKU+FJMhOpwgD8An/FTgEzNEDSVKepN1nrudLI/aQDZH8c4+HRPdJ1i2GdAWGDok y7Ii18pMNDBFAsh9i3ixZZwfND4gAs9qfMBGO63cjTvOTz29f6V6+bnR70ncCaxrfmBQXXvbuuI7 tra23tM9ddli8sVb6snGssnc2amFt6qvvnvgbHG84/LCGG/Jb8b3E+BkvwQ49ahMsXP7s4hCQqAN iID36xiBYUDuRhRJHwX6wBg0zjESwgGUBsq6IHnBQG4QpE7j2wugN6ly1m72y9F6csfo3ep2NsAO qn9RPxntgVUwpQv7LZQ45FPsIOP7Qf+GUBgkCwlsF36BB/xh3hYqDtlZaZhOx3576U3cTZ7jzl6a Q3mQ0vYPMIcJvTCMGICvDJiQVSAzGt3GgJFBepPBYhT1cQbZmMxksEFD0FhsKDbO0Vcbthh79L3G g/ojhgeN9nxDkwHMAccaKJpxZmsB120SCwjNOGJg9EG2lA2xYZZl6QAXNLNGxDKCnhGMeo50oRNm ZMYcdJ4EncltF16IAgQCwKsXpCKqkKg+0pRTdlYAtBRuAa4FrECJUsxAmfJ/ULerX6t/g3QYn8Zz 8M34NPPZ6Gay67KbOzvqIH/R5I7irNP26ZRSPYcoArmPdAuEJ05CEC/yHn4GruY3CTwimRjzRNBh wjI8w/j4LAjH6nEIh/FGYH5MBAVAFbrRCaMR4D4BZENGDMpfQ4F0s3R3AYUA7HEAkICtoFhQhRoT IH6hmEwWagiocQJqnCwWukhYMLU0AavCkIgEHo9iFDAh23nBDtK2S7MaTaCAUcvta7zjeAPyvE7d N7pbfRT/lsg4xKiXCSjaZ5h5IBBLxz7lO7hvIWL3oUolJ4VLE9KMYRwGzusyCo4+gz5Wn65n9Ky3 j2McTBLDMDYLqNWk0iTsBm3h17TFxQuotOUC/KgQicjrQZKW42k4TxMiqh/MoFipegX9wHeonWq/ +jO1E/fjpbgDP6AyhfnTcnLvvqn6rvyc0qk5OTtnztxJ/qw+pLbgX+A2GPSYumjUUzG8beepKSX5 k0sK/3373S8VFxcWUdnSdAC3B/ZMhHOBGUpMvdhhWc8yMX2CoHf1AXNJ26agmVQBaCJmAhHzyl7F S2KELv0LHvHihIhRXaCJmIaJZhbAAAD3aIbhJwqB21M1vemDX/yX2k027fvXmuZF6tqKzJI1i8pW Le4KJHmZS22vTG9sVoG1srOLh3pLF1hdnFrm8nuarsLMNwLMZoB5s1JnEmPFDHGqOFtcKM6LqY1d IXbEdolGSbzLIlty5XJ5rczIDt2BUmmO1CUxkmQXDjgYiz0s47AFo21xcpzdYvF6KFo6a5cd0JrQ HNaiouCFFmCu3An1YS1qAQ1C7TO4XzdqOZAW31WEqSVk8aTClM7KPRsWbk1PTSK3qAF1+aC6nfT0 nK5vWPKzfay+sDZaFNTVVo9cczmfJI5+zJ1NyMl5ZNPRtyoBUYxWjn3GdXBfgx07NYwSx7oVM8iB rhsyLkFvLpCHxv5TqYKC0eV25eMp7ko80z03t12/Qb/etil6Y7aJJ7BzUmyAjWdKwXnwJh2IZz1C lhAWGEEwHmBsnsC2WGmbJ1bbXj1MhVAetWSfU7VZVHQheCF4nTmTrogYG7AHpkh5gZlSZaBZmhe4 TWoP3CGtC4CIUadFCEQHiCZtmvXDduQFAyjlOtlxj2CctcFHyJuMvDkstYVwJHGN0YHXuQ51jzoy rF7YlL4Rp+z2rfFnFNXXNrxUd+ooHNokHcDysrRm9dLurEUZKYXN2+qO3PLML/DvP1QvTM/B7Ys6 TGZrfl72DJvd55569sG3sFAUUJ++qTXKapmaUlwaK3niCl+lvIQRnC5xNcBLAspQYjG7H7QRWoC7 uAVd1MvV60S9ou/SMy0SdXvOj54HNh+F05QrVoSrUYNqtxrkEtnBS3NYML4w59Njn3LnYE4JFSpJ ksCY+vKYSmY9VQFiV7d0v0QkyabYsK4LCfcJj8BmgDtILRVIEVUHuTC/pgZiYBk79QvyJC93To2o w3AP4u3b++6/G28nbtDH7+NkbGNOXl70YH/fY8xjgBNB88f+kz3J7oAzxCzUocywuLiMGFc1Vx3X xDXF3cYts9wWtyFpTVo4Mwp/J8sBZ4oSZSlISfEdC4hRx5zOLBln9QRfzAnmYEuqnEpSU4WemJey QeEChGA1RnNyqLADHYIBShZN5PMgBrlOUUVrVV9ict5kcGr8BbDldId9EjhAHtYheZm66oGM/CKT K1qpyF+dHj8/OW9NxaPvrWpvw6mP9B9sej3DW4TxXTgXS+qDOOkr3mGWpuf5Mux2W0avc5rVFf0f D9zxEDhier5lRqmELZa0l18fZTX8B8a+4qZB/CCCX1Oo+CtxZfwtlg5LF9cVw9sPm0U9cvczTp20 A52S+Whjj24YPBrAClSyhljphDoG8FME0GHSNNC9VpB3ioKkKWJumvrBB7fuUyzqMdxZ/y+3v/u5 em/HjtwV2SlV2fftJdPBVj6XmlzI20ffL6tTz6h/Ofy4HD/6htnwFPBHI+zP7ex2lIJ2K74splRf HJPtVphKdpZuln5WTIW7Rl4g3yZv9ZiTPWDN7UNj56gLax4a+0RxQINIjWOWiEUx+ohJLPVjP9XO MjT6/fFHkFNEftHf5Wf8wTTsTwul4dgd/Eup1ODQOITGj7CTgXEXNTBu8zlAlcojddiphyr5IHyb hAFhsD3jUguOqRmT7w9839y0eNmtC77pXvurhlxHcSBt8fT7H3ykr2KlP3GyM3fecEJVdfXHhx4+ XzOjLCdVPWPNinbGn3z48adkhz3DoZ5JDWp71Dz2KfsN7JENedA0JXWmYWbs7SLjSQc8GQ+woxW5 jphFnHCYc0p20oNeTHTv0L3kBSTGGbD0AmVBCnxLGgbm8yUS6Rr0YMGvA579Ru1veXz5mR/rb6r4 VWv7XRUYjGhyg2/fvjV3Zq9aP+smXIJN9300p6Y+4MUfX0okKaJ58OGjh5JAluheXWZ3QiwVh1Yp 9X4SMOSSEkM5mc3NNpSbZ4nN3ALDPPcy/jZ9yB6KXkc269eZ19nt+Lu4OFPMMauIdKKuXrdEt1bH 6XRsv8mp1zt70KmEYAKOwz2Wl+I1YwN4gZc6ETlckSmvxmoa3X1XPAMpSUNMYC9ffk03/Pyac9NS t7y3Q/2l2o/n4TRsxXb1AWZ5uHOnDv9Xz966oPrH7AycBQfbTlwJLu7lebevWbEReDAAgeJ2PgFi YkWBqJvtd2CjznxMskQZ4DNBrCVWjiU6i04y9VgWRa2OIlHANxD0BWksGyzSHOqiIqoCQFcBrwCj xGOvgwqLLy8X+IgyEbPd7ZqdsbwGO9Uf1f4HHvjg49rtOZxJsM5aqb94eT+z+qL85ptG/Tg/qE3s NyATyWDt5imFNztvzrw5t8XZkrvMuTx3m26Lab1vS67R4XcFjnjFZEv2YZfBYD7Cx+n1bn+KA/gj b9IO90sQrl6gPkkOkBBR6MBDp6abBqtJ48EqMLqUO07YaXgqnLT7EtE1zin4Kec0z5372f3r/1Sf UXa6pm2bV46b/vPWr8fQzTPKXm1fcGhqFG5R++Vm/759mzfmd9718/emTiuIs+OY2EBSoqetygHH IXE4cc/rNVU3B5JzLo/h0SjLL/oe706kevpRyOK0cw4BZSte7ufjTjID/rEFsw+jHu5hhEVMcK0+ pA+DEbpigTSHkcYdBUBwYoW97zSoPXgru+RRLAE5YX8HYG6rNne8YiXQ0DMxFRfiwhydiuq68ehl fAYYPP6ecA72IRXdqkxnnUycIy7Vdcz5pPuk84Rbl3woVpSiZcKa9YfsosViTuiRB6JxD5GieswD iIgErvQ0lJ6VXpseTmfHzSZsiHihSFOusBnRReP6FVjlqotLHSfHuObRcjAQVzvZi+phndVaXZbX lkoxbRlYunoga8Ubi0+8rB4WrNLM8sz5TNzl8yS7bq3f7w24Lp9nl2ytrlsSWtD5/pnRJJJdvwba 4bPXBH6cFfBzgmXwYYfNUSKFHSwWo3SHbKLZEoWBlVxZrpCLiMaeqGE44gIPF7gKiHWFkbwabOOx uwZ4PuV2B2dVD5sl++zK7PZiCmdocMWJMySzYpcHWMGnAVVT+/t3YN8bxz7ikkGn0NjBq1gd/XrR CwbJAvYoyQ2q2q9xMfgCcNpyxRWYiAvy4WvOPzk34JLVl9UP4X4ZV+JEcAmmq5U+n9/jaZ48eW6S NwW+9zQVZTeRbFABr+JS+IYUjaepI6PvBzbftmRnalpiXHrK7qULd6Wl+L2UTgQNqG3cNKAT1c+l SqCCVFgqPHWWOlu7pc22WdcVp48+LIkmS8IR3ml02wH0RLNb32Ma9o6bUqAYEAx+2vEAPdCg1vQq ua5aU+3Yg5s2r/KmE52hnVWUcGBO3/5SvTe8Gcypvy6VmtM952feXJuWpGZwY+vBnr6hfv3EQbCn vzXrjgGszWqbpjsorMVKCrUlsz0LPLd5wuIWj0DtiNVCDQl232BKJlTFdXB6wcLdYEj+mzpQ+xuf WvbmD5ohWXTXTZr4X7UkahsxzKi6ZkxA4N+5Zks0mWTeY5fCV93Ck9gUNsF5phayR8NpIXvIYjFa 9PB91B60Y5PQox+2abwH6hYgLB0NUFXbMqFrhesEhnnPE92ROHtDBaXdxshMW5aVMel0dteoyC45 2lEOsTfI9SKwt1tgP7PQdkXMCVa7ZgTX483Gze71PgECiU8UrxnCCg9kxRLokNhUiBlqIWagrgYE DsfiRYE6GTYalgvmY4zTm7ojVtrhjRW02MGgxQ454RwMviyAHACdezV6CIz7GzR8gPCJnjDYWa+m h+EgTGOAcaZOSQZ30U9DRno6Nu57QD/82C3qa+p3hy/O9LpnTC/cN3d5R0lD6j2FPzsI/qHhzi+m y7Vnlt2yMb+toEvZtxu3/fLdwkScasuMjfYGJ6UlSXqHJfXpOx//Q268er6gMisjNd1hdIhJjwBd AmNfMZu4J5AbzVQyDJybIxZj2EiMYpRwzGiwuN3RgKtZgZEo3hKPdVFij0G3WqBo5uaCgdHcdvCo oFiqGUjAsCWJslFyHjWF2kZRL348gC/IZTZN2X7r22cOHsSdeK76LLGYZ1TELbAmGCzSwJsk6iKI 7isX1TXFjT5fmgtMMaz8GMQTevhC7wRPKc3Ax/KzbAtsK2xdwhabQByc3iIdAubWvKRx1UVdWno4 rznrmks7bgInPCWA7DqIILTQq/1tT6598Td4udFum105KTwZd26dNefcWfLB6Dvzbk9KSkz0MvTL NUYJoBeiARYB3auU6riZXCPTxHUwHDRw8OX4GTwM9moXPat/QjghEGEnz/FGRuBccAQS4AqZ5dwd BM5WuXW8EY5z/qj49JYC3gsZQVweX8kT3sKxbkL0Qf0cOPmGUyPCQ9ShSQE9OqemHE5U6Ul5Cz0o bxnRwY1b6JG/14a95ChGeM3o/eqW59QavAXfS879A+Mn2AV0BxFH7htdlbV6kaXkB+Qe/y/Cr8+9 VwE9SHu61CbhHHhFGM4aQWy0C97TGdU6hMyFl46OeaOoB3/jlayDJnIKpLkJvQrpSa4H3cHnIxfv Qqe519FS/gl4ToYUg04Lh9Bp/j8gnUFLuY/gWQbtz6KV3DqUxnehp7lGNJ/rRwPsC6gRns1cLWpk WlGAlmGNRyEN6DaiAe44pDu1MQO0j/kHvPMKWsQchbHH0WNcHvwTBCEP3J0ogj7Etfgt0kaGyLeM ldnLEraDHeEmc58DhWv5twSP8Ljwo26xbkDv19fpV+k/NngMawyvGeOMzcbPTYWmO00fwmwU82R0 K5yEdsLpKIEIS0HzwFxweAm00V4M2o0+4SgQbAdqnFNWNX92YH77mrbWVa2ZZatXtNG+CdqOrUfv 0Op/u+g/hhjt3zBW+IaRBGumQKQeBO2VjXLAQ8xD+agAFaIKVImq0Ax0E6qGU6pZaA6qRXNRHapH DQDXfHQL/P9iIUKKvuHPX/jlLz6XQNWNKG3nTGK+8r/wH/ok+QykNyD9FtLrkH4D6VVITz/olx+C 9MCDHvlnD6bKD/a55e/6HfKx/hj5SH+6fLg/ST4EZaUf98Nwy1/xwb4Y+UBfQN7fB75GH6YLLewz ivmWU/Kp4Ckm+BJGw+IwsQxh9AL2/L3r70T8m+dvyt+Yrh+weNFzkXi+qf2GBL8u/XrO10zWu+F3 yfHnUuXnjkty8Hjp8VAkHAn/nvvsvF/+E6TgebrA8V8BInShseeh8HbXJPkspLe6PPLvuiR5BNIr kO47PXaaWF7GYy/jwWclOfwsFp/yPEX23JMl994TlO/pypV397jkXZB29lTLd/dI8o6eKXIPTLN6 4NGByMC3A6zyGBYXehYqC5nvYcbtXS75rq6Zcjc874QVt0Gq7Qp1hbsY0eKVnY50WeC9cowrXWYZ r2yzpssZmZb0gDk1zZKcYvYnWRJ9Zo/XkiCb3XHxUa6Y2CiHMzrKarNHWUTJZIoym/QGowm+rZkY ljMhTEyipdtCFL6bh8+T3QyxoFLY7C7EWoArSpESvxoqr6DfoTGkcxfrZMsUncwU6WRUqJNrc3HE WoNqGsoiNgzP+rJIbqBmSIfqIjmBmoi+dkHjIMb7mqA1QnbD9jRE2N1DBB7W8uYFjUM4hnbfrf2t AkpDuPvue+91Xy01NQXiI2019Y2RcHxTJIcW7o9vQnCSHli7bu3atbTwz65BPV29ra5s8EuW/umi NfKlr2Lwqy+1P2BEvvJV4IlXr58DpoNJr0wHBfq77kKB9dC5NrDuypCrT+0lEKv/Dejav+QKZW5k c3RyZWFtCmVuZG9iagozNSAwIG9iago3NTY4CmVuZG9iagozNiAwIG9iago8PCAvVHlwZSAvRm9u dERlc2NyaXB0b3IgL0FzY2VudCAxMDA1IC9DYXBIZWlnaHQgNzM1IC9EZXNjZW50IC0yMTAgL0Zs YWdzCjMyIC9Gb250QkJveCBbLTU0NCAtMzAzIDE3MDcgMTAxNF0gL0ZvbnROYW1lIC9YT0JGVk0r VmVyZGFuYS1Cb2xkIC9JdGFsaWNBbmdsZQowIC9TdGVtViAwIC9NYXhXaWR0aCAxNzc3IC9YSGVp Z2h0IDU1NyAvRm9udEZpbGUyIDM0IDAgUiA+PgplbmRvYmoKMzcgMCBvYmoKWyAzNDIgMCAwIDAg MCAwIDAgMCA1NDMgNTQzIDAgMCAwIDAgMCA2ODkgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMAowIDc3NiA3NjIgNzI0IDgzMCAwIDY1MCAwIDAgMCAwIDAgNjM3IDk0OCA4NDcgODUwIDcz MyAwIDc4MiA3MTAgNjgyIDgxMiAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgNjY4IDY5OSA1ODggNjk5 IDY2NCA0MjIgNjk5IDAgMzQyIDAgMCAzNDIgMTA1OCA3MTIgNjg3CjY5OSA2OTkgNDk3IDU5MyA0 NTYgNzEyIDAgMCAwIDY1MSBdCmVuZG9iago4IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBl IC9UcnVlVHlwZSAvQmFzZUZvbnQgL1hPQkZWTStWZXJkYW5hLUJvbGQgL0ZvbnREZXNjcmlwdG9y CjM2IDAgUiAvV2lkdGhzIDM3IDAgUiAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAxMjEgL0VuY29k aW5nIC9NYWNSb21hbkVuY29kaW5nCj4+CmVuZG9iagozOCAwIG9iago8PCAvTGVuZ3RoIDM5IDAg UiAvTGVuZ3RoMSAyODc2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZ1VfVBU1xU/ 9777lgV3eQu8BWUDb9cVqC4UXXZXqZB9IAvo0gkiMGBDZBHiDoKsQhAbpxInqGyMYhI/xqSpsW3S pJ1kXSguBiNKQzRprE6bTPqRqfYrZqYmZsbkjyhsz3uApYl/9e6ee8/5nftxPt69BwgA6KAXOJA3 tvsCUAqvIvJbpN0bu7vMFSeLKACpRDr2aGBT+/hO/xUAegPl+k1tOx4NX37wCAArAeBEf4uv+atN W44DxNThepcfgaSVmnqUB1Be5G/v6pH2ce+hPITy/LaOjT76C8pQVs6Lb/f1BHg99zeU/4KyeYuv veXThds3oXxXkQMdnV2PVbR/CaB9AOWCwLaWwI6Wj6Io43n074gR/ClNBxroxtEMrhlEhf/vDmNw r3GAFt+38QCadI3I3+Kvsp2sgfsYDADRT6LXp3qmmqfquedAwnVH4DUYgQm4fG+PUbig8t0QhjHA +MxpT8Bz8DLm40/w+T30GLwIv4TQPVlhBkBBf4bZex0G4QyMI7YPDiH6c/jVnJkdsBcOwvNwAn5P 0mbwcSqSaQs+BR29SjrJAUiFbCiBh6ETfgR70K6LpAKxQsQqEd0GPfAMoiNwcc7es2wh1EIDtMIW OIUzzqvwElxbDc2IKth02wo/hH54CV6BN6ED+b1oL34932pPUAu1QBf8E1e+Sw7TCfToFejTiBAH wF9Vosoa1NhC9DrAVHMUvxGuid6mJ+kheIO2QoUcX1O93JWZISUl6nU8o9nmEJfhsXqsPn/Q7PGb g9aSxpKcbG9VnafEZLHU52SbES4xh0ij2RMq7fbPD3qUCaFEW4hmeBRqDclPNSJjLbFYLKhJ+q8m Eh3bP0d1CvAsf3WdcqRCjX5ziOE6tTMhMmOBovM3Ym8tQQPui/+PiaXW0sZgsNRqLg02Bn2RaG+T 1WywBk95vcGAp9Ecgsq6EEH8zFOmUOn++pCh0U++h54pRpRW1blNlgQ8x7vO6l27vs7sCTbOuD6D rJgOxCkKxWgNXVVdN1eBSiVOSrKoculi8MrhKxID4mkN3mmFct//+H21W7bUkmBJyMCO4Kyve3m4 o4yAjNI45SvibZhJIyyCPOiX7bzOqMvS1dBa464FmsSEbEd6ekyaQ8vlOGK0ycbEbCFTr9fUCGad DnshJsMIkeg/hhQMmRuyQcFhq1Nwyk6ani3GRKJfqFqFGVaUMW0Ow1c226S9QRluJubn2myJ+TfB fdOtCDfz85ctJQ1E1MRoNFY03J6ckpxsRNGYnEwcmVmZmVYroq7lLlfStKhMUkTeVl1Wfen5yVtk 5Kcn11StaVt/9PWpwUXfyd2z8d8EGrbk5mbtcpUt7W+aukQ0u192rnCQdzteW168gr86P9O295HW wzla6T3KXGtSTPqpqqT09A2Tx9e3ZiwQJj80LcpqVl45JV4rMV7z4GE5h3OC1qClWi0fF8MRXhtL RRDUUCSpYejRC3pZX6nntJzIR6KfqYFQGDUQfJtuTiAm7eAucBdgBLbexKyhiwnWhDzs8/iVE5ML JiboJxP0j5NZ/NXJCC3H3BG8wUA/UG35rrwgltk1XBxnJ1p9e5x23vo4kePpeq4dz7htN0wi/Qvc k3b84+4WZ16C1Wkx4gn0g8mh8XFaMT5+jL107NidDcp3QSAcvc4vxr3T0M88a6J1fiFXGFvBVcRu T9qeon1AzxkdmjgTvgOqu3Gqu92SIEmSLHGCqItEb6veKozqrW5zuprv6awr2S5YtnQ2zQuVtDrR XVFJdp6aTRT5xWVrv3+5f/+VsrVlE5as7KOtm4/kZFkmaO3JLyorSteUV914lXv87uM79ucXFRcV 5z/bzgXVqkM78xaev/vWBqHgSzBpFY/gnQ8/wlo5M/ZHr6u3BiAWZisMXiXtvKkqLGHZ0eN3/jDv WXUnZcls02gRoliF+Z1wUYN3h3sE+vk/42sMYMZfBKZINgmipFxLDTTh/doMPJ5ggFx8mYEdxlrJ qVoCieqozIsHqCuqr/KustW2bGv2bfHN2hStwNf+fg0vPKGEI4zwRMN3BnwbW0gxKSerSc0IVEfH 5PTwYrvLEDaH5XBlOBDuDZ8Ih8JXwtfCcWPhW2GKz6Qc+HXKfJdUQoRaqZY+VLOhhnZUk59Uv1FN 165LYVXrktm6KiNbs7qKla5ezspW21k50mpnPitw21mhu5A96LawVe40VuyuYkVIMpLbaWf2vGaW 53Qwp6OaOZzp7IrjmuOWg8PvfnAoo9wViV4bHDJYcfxM1g/FCq6h1HLWPbhnEM26NTiozvhajg7G LnINiuWsf18SC7QFeqjwwl9fpPKPkxe45BeSTS75aApyR1JMrj19SZLwpNAnHBAOCgPSk9IB6WDu gd6+3n0HDw30Dewd2CfIu2MNLmGbtI3KW2N1LqGdmC8S8zvEPfH5BDW/Lb9NoYlAk6GJyr4TPir8 gOSICSxbzGA2MZ8tEZPYYtHIJDGdWcyrmFksYJdSPSzVVMZMqQUsVbQzI85LQnMTxVSWgBQQiSwW rXIJ8Usk0BD9uFfSXfBKcWNeKRaJH/VK7KxX4ka8Ej3jlciwV4LTXmn8whJp7NwS6axcO2qRzoxY pNPDFunC+G/058bO60fPvqUbOfOmbvh0RGcY7R2l8kjvCBWG3cMPDe8aZsJwLrIdyJ4b/t1wdFgb F7uc6fQUyy5HsVbQSp5ESLTv6afTQkew4oZ60+ojWvBigSQhcqA+pPWum2HBprTOrs5OlflGF+I8 IY3H7wtprCWdihCvCPFYWOM9IUHhBWuJjYREjz8kIvetTTpnG6qmldMHqTw89o3jVFGxpQststng PyLxu9AKZW5kc3RyZWFtCmVuZG9iagozOSAwIG9iagoyMTI0CmVuZG9iago0MCAwIG9iago8PCAv VHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCAxMDA1IC9DYXBIZWlnaHQgNzM1IC9EZXNjZW50 IC0yMTAgL0ZsYWdzCjMyIC9Gb250QkJveCBbLTUwIC0yMDcgMTQ0NyAxMDAwXSAvRm9udE5hbWUg L1hBWVJLQytWZXJkYW5hIC9JdGFsaWNBbmdsZSAwCi9TdGVtViAwIC9NYXhXaWR0aCAxNTIxIC9Y SGVpZ2h0IDU1MyAvRm9udEZpbGUyIDM4IDAgUiA+PgplbmRvYmoKNDEgMCBvYmoKWyAzNTIgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgNjg2CjAgMCAwIDAgMCA3NTEgNDIxIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA3MzIgXQpl bmRvYmoKOSAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250 IC9YQVlSS0MrVmVyZGFuYSAvRm9udERlc2NyaXB0b3IKNDAgMCBSIC9XaWR0aHMgNDEgMCBSIC9G aXJzdENoYXIgMzIgL0xhc3RDaGFyIDg1IC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+Pgpl bmRvYmoKMSAwIG9iago8PCAvVGl0bGUgKFJQTC1NVVNULnhsc3gpIC9BdXRob3IgKEpQIFZhc3Nl dXIpIC9DcmVhdG9yIChNaWNyb3NvZnQgRXhjZWwpCi9Qcm9kdWNlciAoTWFjIE9TIFggMTAuNS44 IFF1YXJ0eiBQREZDb250ZXh0KSAvQ3JlYXRpb25EYXRlIChEOjIwMTAwMzI5MjIyMDUyWjAwJzAw JykKL01vZERhdGUgKEQ6MjAxMDAzMjkyMjIwNTJaMDAnMDAnKSA+PgplbmRvYmoKeHJlZgowIDQy CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDA1MzkyOCAwMDAwMCBuIAowMDAwMDAyMTk0IDAwMDAw IG4gCjAwMDAwMTI0NTkgMDAwMDAgbiAKMDAwMDAwMDAyMiAwMDAwMCBuIAowMDAwMDAyMTc0IDAw MDAwIG4gCjAwMDAwMDIyOTggMDAwMDAgbiAKMDAwMDAwMzMzNiAwMDAwMCBuIAowMDAwMDUwOTg0 IDAwMDAwIG4gCjAwMDAwNTM3NTcgMDAwMDAgbiAKMDAwMDA0MjYxNyAwMDAwMCBuIAowMDAwMDAy NDIxIDAwMDAwIG4gCjAwMDAwMDMzMTYgMDAwMDAgbiAKMDAwMDAwNTQwOSAwMDAwMCBuIAowMDAw MDAzMzcyIDAwMDAwIG4gCjAwMDAwMDUzODggMDAwMDAgbiAKMDAwMDAwNTUxNiAwMDAwMCBuIAow MDAwMDA3NzY0IDAwMDAwIG4gCjAwMDAwMDU2NDAgMDAwMDAgbiAKMDAwMDAwNzc0MyAwMDAwMCBu IAowMDAwMDA3ODcxIDAwMDAwIG4gCjAwMDAwMTAyMjcgMDAwMDAgbiAKMDAwMDAwNzk5NSAwMDAw MCBuIAowMDAwMDEwMjA2IDAwMDAwIG4gCjAwMDAwMTAzMzQgMDAwMDAgbiAKMDAwMDAxMjIyOCAw MDAwMCBuIAowMDAwMDEwNDU4IDAwMDAwIG4gCjAwMDAwMTIyMDcgMDAwMDAgbiAKMDAwMDAxMjMz NSAwMDAwMCBuIAowMDAwMDEyNTcwIDAwMDAwIG4gCjAwMDAwMTI2MjAgMDAwMDAgbiAKMDAwMDA0 MjAzNCAwMDAwMCBuIAowMDAwMDQyMDU2IDAwMDAwIG4gCjAwMDAwNDIzMDEgMDAwMDAgbiAKMDAw MDA0MjgwMCAwMDAwMCBuIAowMDAwMDUwNDU5IDAwMDAwIG4gCjAwMDAwNTA0ODAgMDAwMDAgbiAK MDAwMDA1MDcwOSAwMDAwMCBuIAowMDAwMDUxMTYxIDAwMDAwIG4gCjAwMDAwNTMzNzUgMDAwMDAg biAKMDAwMDA1MzM5NiAwMDAwMCBuIAowMDAwMDUzNjE5IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1Np emUgNDIgL1Jvb3QgMjkgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDxiN2Q3MTE0NjUzZjY1M2Y3NTI3 Mjg4YjQwODJjMzU0Zj4KPGI3ZDcxMTQ2NTNmNjUzZjc1MjcyODhiNDA4MmMzNTRmPiBdID4+CnN0 YXJ0eHJlZgo1NDE0MQolJUVPRgo= --Apple-Mail-196--214437086 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Any chance of getting that in a = format that we can read without spending several KUSD on special-purpose = software?

Thanks,

Thomas
On Mar 29, 2010, at 21:31 PM, JP Vasseur wrote:

Dear WG,

I = put together a spreadsheet to track the "MUST requirements" spelled out = in our four requirements documents.

To that = end, I listed all MUST and used the following color = code:

GREEN: Satisfied = requirement

YELLOW: the = requirement is partially satisfied and the WG thinks that the = requirement is not sufficiently satisfied.

For = example:
Support of = Point-to-Point: "The routing protocol MUST provide routes between = arbitrary hosts within the = appropriate 
administrative domain". Strictly speaking RPL supports P2P but the = WG thinks that more work is required, thus = the 

RED: the = requirement is not satisfied (e.g. additional mechanisms required) or = not yet done (e.g. security)

PINK: the = requirement is partially satisfied or non satisfied but the WG decided = that this was acceptable. It may 
be wise to document = it.

GREY: Evaluation is differed (not a show = stopper for LC). For example, it may take time to deploy a network = with
few dozens of thousands of nodes. Note that in this case, = simulations may help.

Let's continue to work on = our opened tickets and update that spreadsheet = accordingly.

Note that in both the = YELLOW and RED cases, RPL could not be last called until they turn = GREEN.

Comments very welcome = of = course.

Thanks.

JP. = ;

<RPL-MUST.xlsx><= /span>
=
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll


_______________________________________________Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-196--214437086-- --Apple-Mail-195--214437088-- From robert.cragie@gridmerge.com Fri May 21 12:24:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2DC33A6953 for ; Fri, 21 May 2010 12:24:28 -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 3v5GUKBVaXLQ for ; Fri, 21 May 2010 12:24: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 1C24A3A6821 for ; Fri, 21 May 2010 10:07:57 -0700 (PDT) Received: from client-82-26-125-25.midd.adsl.virginmedia.com ([82.26.125.25] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OFVhK-0006Wi-2E; Fri, 21 May 2010 18:07:46 +0100 Message-ID: <4BF6BDE0.9080106@gridmerge.com> Date: Fri, 21 May 2010 18:07:44 +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: JP Vasseur References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> <039a01caf88d$5b4e5d60$11eb1820$@com> <1274424605.3101.128.camel@d430> <115B81B3-7678-4293-BE38-F35E7ACA2D8D@cisco.com> In-Reply-To: <115B81B3-7678-4293-BE38-F35E7ACA2D8D@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030401000602000807020408" Cc: roll@ietf.org Subject: Re: [Roll] whither draft-ietf-roll-protocols-survey-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 19:24:28 -0000 This is a cryptographically signed message in MIME format. --------------ms030401000602000807020408 Content-Type: multipart/alternative; boundary="------------010607070302030305090105" This is a multi-part message in MIME format. --------------010607070302030305090105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Perhaps the title of this e-mail should have been 'wither=20 draft-ietf-roll-protocols-survey-07' :-) In all seriousness, this document should not be allowed to disappear=20 from the process as I think fundamentally some of the assertions made it = in were questionable, to put it mildly. 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 21/05/2010 11:25 AM, JP Vasseur wrote: > > On May 21, 2010, at 8:50 AM, Geoff Mulligan wrote: > >> What ever happened to the protocol survey draft? >> >> Samita's message about the proliferation of drafts that atrophy got me= >> wondering about the protocol survey draft. This is a working group >> document and is part of the milestones and charter of the ROLL WG, but= >> this draft has long since expired. >> >> It was supposed to be submitted to the IESG as an informational RFC ba= ck >> in Feb 2009. It was last updated in April of 2009 so I would think th= at >> it is complete. Why hasn't it been submitted to the IESG? Given that= >> it was THIS document that was the basis for the decision to create a n= ew >> routing protocol it is important that this information is not lost. >> >> Did the WG ever even Last Call this document? > > The decision was made not to publish it as an RFC (see WG minutes), als= o > in agreement with our AD. > > This will be reflected in the Milestone when we will work on them,=20 > with the WG. > > Thanks. > > JP. > >> >> geoff >> >> >> _______________________________________________ >> 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 > --------------010607070302030305090105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps the title of this e-mail should have been 'wither draft-ietf-roll-protocols-survey-07' :-)

In all seriousness, this document should not be allowed to disappear from the process as I think fundamentally some of the assertions made it in were questionable, to put it mildly.

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 21/05/2010 11:25 AM, JP Vasseur wrote:

On May 21, 2010, at 8:50 AM, Geoff Mulligan wrote:

What ever happened to the protocol survey draft?

Samita's message about the proliferation of drafts that atrophy got me
wondering about the protocol survey draft.  This is a working group
document and is part of the milestones and charter of the ROLL WG, but
this draft has long since expired.

It was supposed to be submitted to the IESG as an informational RFC back
in Feb 2009.  It was last updated in April of 2009 so I would think that
it is complete.  Why hasn't it been submitted to the IESG?  Giv= en that
it was THIS document that was the basis for the decision to create a new
routing protocol it is important that this information is not lost.

Did the WG ever even Last Call this document?

The decision was made not to publish it as an RFC (see WG minutes), also
in agreement with our AD.

This will be reflected in the Milestone when we will work on them, with the WG.

Thanks.

JP.


    geoff


_______________________________________________
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

--------------010607070302030305090105-- --------------ms030401000602000807020408 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 MjExNzA3NDRaMCMGCSqGSIb3DQEJBDEWBBRcKtbMz2Cvd9QYZXNWSKX6lSh4tDBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBABpYd5vDaiFsU+MV0ijCszA8ofCf9bB2tg9agzc0au1i5k2yzPpXoJwayGxK8FnDXi2l 6Rj/XU9PKXmr2T62pSpwF8yg0kkfyjs9Qofpm3MX9l9VpGGsYxeMBR+ljc6UJD4gg56R0aH5 Cb/LmF80bijvsTlhSu4YD0wBkgwQ8nHUs/WL8dHmj7eIjfYrKcTkk/NqnCMjY1mzmRNigPgP wWpzdMl1JxorgBE4wH61/h+VSRxbPAYASjjcD4MuzDmjC65xmybn/CYAxzukL7v/dPEvDGTl PsuCZDFhO7m8TmXqg+XdJCK7iOdLJilChZqE5yNq+iUe+OuCsuZ5ZvnjZkkAAAAAAAA= --------------ms030401000602000807020408-- From robert.cragie@gridmerge.com Fri May 21 12:58:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC303A68D1 for ; Fri, 21 May 2010 12:58:58 -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 tqDZ56h6g4ig for ; Fri, 21 May 2010 12:58:57 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 8AB833A8166 for ; Fri, 21 May 2010 06:56:05 -0700 (PDT) Received: from client-82-26-125-25.midd.adsl.virginmedia.com ([82.26.125.25] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OFShc-0006vR-PL; Fri, 21 May 2010 14:55:54 +0100 Message-ID: <4BF690E6.1030008@gridmerge.com> Date: Fri, 21 May 2010 14:55:50 +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: Carsten Bormann 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> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050109080508070304030809" Cc: ROLL WG Subject: Re: [Roll] Source Routing Header Format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 19:58:58 -0000 This is a cryptographically signed message in MIME format. --------------ms050109080508070304030809 Content-Type: multipart/alternative; boundary="------------090707080406050101010106" This is a multi-part message in MIME format. --------------090707080406050101010106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable That's a good point. As far as I know, we got to the point of specifying = some hop-by-hop header containing a specific RPL option (which I believe = Jonathan is working on in 6man) using labels. I would hope the same=20 underlying principle can be used for both route record and source=20 routing. Otherwise, we are back to using addresses in headers. If this=20 is the case, we really need some way of compressing them for 6lowpan. 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 18/05/2010 5:33 PM, Carsten Bormann wrote: > On May 18, 2010, at 18:21, Pascal Thubert (pthubert) wrote: > > =20 >> Then 6LoWPAN can work on compressing it using 6LowpAN >> techniques. >> =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. > > Gruesse, Carsten > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > =20 --------------090707080406050101010106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's a good point. As far as I know, we got to the point of specifying some hop-by-hop header containing a specific RPL option (which I believe Jonathan is working on in 6man) using labels. I would hope the same underlying principle can be used for both route record and source routing. Otherwise, we are back to using addresses in headers. If this is the case, we really need some way of compressing them for 6lowpan.

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 18/05/2010 5:33 PM, Carsten Bormann wrote: 
On May 18, 2010, at 18:21, Pascal Thubert (pthubert) wro=
te:

  
Then 6LoWPAN can work on compressing it using 6LowpAN
techniques.=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.

Gruesse, Carsten

_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------090707080406050101010106-- --------------ms050109080508070304030809 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 MjExMzU1NTBaMCMGCSqGSIb3DQEJBDEWBBQCdVmRS6TKP1m+U7CYc4o3kxmvzjBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAF8UIdbF4zhkDmfxHZMjZBpBYHhLu4+ktv8/Wa8H/cwursxfZ8fnZqEvUIV4Pv34ypcL Rv/9ly9fhmpFxIi7AYqgNpQ+A4G0+EJbLHlMOQnydrTEu/OEltbR5Q6vxLXJIgPqN6zTytlO gseZaeJO4r2Sd3frTn64uvjYI5RIx+mt3b5Y97c1RwsVtvskdM/5XmyvcLaUmcRWeiDhO/OG WZj6+XneCvX+gK3k/ZeXR7MckTjNoIk57pRKAjGo+qrdMK2de3LWia9UOHN7Hbts3vyaw1Vg /Vi5Z1mx656VoFlC6CiegxuoYW1tZohzRpQe7J/pggoyDs6COl54wr3wNeUAAAAAAAA= --------------ms050109080508070304030809-- From Jerald.P.Martocci@jci.com Fri May 21 13:13:51 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64E83A6DC2; Fri, 21 May 2010 13:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, 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 1UHnEHfbujXl; Fri, 21 May 2010 13:10:17 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with ESMTP id 9BEAF3A8295; Fri, 21 May 2010 07:13:22 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKS/aU5ekqPGvK84JKIBTVhjryD/FJjv4g@postini.com; Fri, 21 May 2010 07:13:17 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010052109131642-2425982 ; Fri, 21 May 2010 09:13:16 -0500 In-Reply-To: <039a01caf88d$5b4e5d60$11eb1820$@com> References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> <039a01caf88d$5b4e5d60$11eb1820$@com> To: "Samita Chakrabarti" MIME-Version: 1.0 X-KeepSent: A0A3F35F:0586E06C-8625772A:004AF03A; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Jerald.P.Martocci@jci.com Message-ID: Date: Fri, 21 May 2010 09:12:39 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 05/21/2010 09:12:51 AM, Serialize complete at 05/21/2010 09:12:51 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/21/2010 09:13:16 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/21/2010 09:13:42 AM, Serialize complete at 05/21/2010 09:13:42 AM Content-Type: multipart/related; boundary="=_related 004E0A378625772A_=" Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 20:14:29 -0000 This is a multipart message in MIME format. --=_related 004E0A378625772A_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Hi Samita,

Comments below ...





From: "Samita Chakrabarti" <s= amitac@ipinfusion.com>
To: <Jerald.P.Martocci@jci.com>
Cc: "'JP Vasseur'" <jpv@cis= co.com>, "'Richard Kelsey'" <richard.kelsey@ember.com>, <roll@iet= f.org>, <roll-bounces@ietf.org>
Date: 05/20/2010 09:28 PM
Subject: RE: [Roll] RPL Status




 
Hi Jerald,
 
Thanks for the  response. Please s= ee below.

With regards to multicast being a separate ID, it concerns me that if we proliferate IDs some may naturally atrophy or be discounted in time.  I believe that RPL should cover all the necessary IP functionality as applied to LLNs including multicast and P2P operations.  If a given implementa= tion determines that for whatever reason the application does not need these features, then they need not be implemented.  However, I think the RFC should be holistic.

That being said, please note that I am a complete IETF neophyte.  Maybe there are ways to assure that separate ID stay in lock-step.  If this is true then I have no qualms about separate IDs.  If there is a chance that some IDs may fall into disrepair, then I opt for a single fully inclus= ive RPL ID.
[SC>]  There is no generic rules on id separations in IETF. But, I was fearing that including all feature in one protocol draft may complicate the progress of the draft.  But I was pointed out that multicast is in the RPL charter; in that respect we may want to have  limited multicast forwarding support in LLN for now. Later, if needed one can extend the feature for more effici= ency of multicast in LLN. Moreover in some L2-networks like 802.15.4, there is no multicast support at the link-layer – in those cases, unicasts = and broad-casts are the only options depending on the applications – righ= t?

I'm not sure I und= erstand the question.  We are currently deploying ZigBee products which incorp= orate 802.15.4 radios.  ZigBee emulates broadcasts and multicasts by a contr= olled flooding of the LLN with a series of link local messages.


With regards to multicast in building environments, currently there are two multicast use cases used in building control.  The first is for discovery purposes.  There is a need for a device to access data items from other devices.  The discovery and binding is done using a site multicast (or broadcast).  Often times the binding will be across two devices in the same LLN, however, it's very possible that the binding may cross subnets.  A case in point is the need to access the 'outdoor air temperature'.  This data is very important to the HVAC control algorithms.  However, buildings typically only deploy a single outdoor air temperature sensor across the entire enterprise.  Hence most refer= ences to the device will cross subnets.

[SC>] Thanks for the real-life example – very useful. Can I assume that an enterprise will have a co= llection of LLNs joined by their border routers in the backbone?

Exactly.  Often there= will be an LLN per floor each with an LBR.  The LBRs will be tied together in some IP fashion, often times by the enterprise IP network.



The second use case will be for different building subsystems (e.g. Fire, Security, HVAC) to operate independently at the application layer, but to share the routing (meshing) capability to increase the density of the meshing nodes.


[SC>] So, in this example, is it fair to say that the main usage would be to address all-node-multicast in a building sub-system? Or there might be more granular usage of multicast groups (per floor, per room etc.)?

Yes.  A main = use case would be to segment the different building system types (e.g. HVAC, Fire, Lighting).  As I noted above, LLNs typically don't cross floors since the low power radios have a hard time pushing messages through floors and ceilings.  There will be application oriented multicasts establish= ed as well.  For example a multicast group would be established for each bank of lights that are associated to a light switch; so when the light switch is toggled, all the proper lights are turned on/off.
Thanks again,
-Samita

Jerry

From: "Samita Chakrabarti" <samitac@ipinfusion.com>To: "'Richard Kelsey'" <richard.= kelsey@ember.com>, "'JP Vasseur'" <jpv@cisco.com>
Cc: roll@ietf.org
Date: 05/18/2010 06:56 PM
Subject: Re: [Roll] RPL Status

 







Hi Richard/JP,

> >
> > Here is a quick status. First, we would like to thank the WG again for
> > the continuous effort and lots of fruitful and productive work ! As
> > discussed in Anaheim, the plan is still to Last Call RPL before the
> > next IETF.
>
> We will have to do something about multicasts (ticket #30).
> The multicast text in the current draft has a number of limitiations; in
> particular, it requires that all nodes cache DAOs.
>
[SC>]  Ticket #30 is about clarification of text regarding the multicast
operation.
Indeed it is not clear and subject to implementor's interpretation.

> Forwarding multicasts using unicasts makes sense if relatively few nodes
> need to receive them.  For a multicast that needs to get to most or all of
a
> network, using unicasts seems likely to be both unreliable and
inefficient.
>

[SC>] BTW, is RPL also trying to solve multicast routing/forwarding
completely in all cases ? It might be better to have another id for the
detailed multicast forwarding/routing for all cases (multicast to all nodes=
in LLN, multicast to nodes that are spread out under different parents far
from each other and trying communicate with each other etc.). It might be
easier for RPL draft to handle a set of common use cases with the existing<= br> mechanism. I wonder what would be the typical applications today for RPL in
LLN ? Is it in the building network where most of the communication takes place from one or two parent or grand-parent nodes to their descendants
using a multi-cast address?
That said, we also need to make sure the current multicast mechanism could<= br> be extended to cover other scenarios.

Actually the current solution of using DAO to store the multicast address and the corresponding members of the multicast address may work out. But I
agree it is more work on each parent node to aggregate the multicast
addresses, process them and store them and might also make a decision to
prune.

If we consider LLN to be a route-over only link, then modifying MLD
hop-limit and forwarding MLD messages are an option but we still need to
consider pruning.
A generic solution for multicast routing/forwarding in LLN seems to be a
non-trivial problem to be handled in RPL draft alone.

Thanks,
-Samita



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/list= info/roll

--=_related 004E0A378625772A_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_095052B809505078004E0A378625772A> /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --=_related 004E0A378625772A_=-- From jpv@cisco.com Fri May 21 13:44:39 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01783A6AB0; Fri, 21 May 2010 13:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.492 X-Spam-Level: X-Spam-Status: No, score=-8.492 tagged_above=-999 required=5 tests=[AWL=0.618, 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 KiVNCIBz5Z+J; Fri, 21 May 2010 13:44:39 -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 53BE33A6E8B; Fri, 21 May 2010 13:22: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: AvsEAEeI9kurR7H+/2dsb2JhbACeFXGkb5lVhRIE X-IronPort-AV: E=Sophos;i="4.53,280,1272844800"; d="scan'208";a="200962878" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 21 May 2010 20:21: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 o4LKKtp7013132; Fri, 21 May 2010 20:21:05 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 22:19:56 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 22:19:56 +0200 Message-Id: <2C73F4C7-6C6F-4538-82D9-66B41E29F056@cisco.com> From: JP Vasseur To: ROLL WG , iesg-secretary@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 21 May 2010 22:19:55 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 May 2010 20:19:56.0577 (UTC) FILETIME=[FAD24910:01CAF922] Cc: Adrian Farrel Subject: [Roll] Virtual ROLL Working Group - June 16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 20:44:40 -0000 Dear WG, We would like to announce a Virtual ROLL Working Group meeting (conference call) on June 16 at 8:00am PDT = 11:00am ET = 5:00pm CET = 2:00am Japan time for 2 hours. This will help us continue our progress. The details of the bridge will be provided shortly. If you would like to request a slot, please send a request to the chairs before May 28. The agenda will be published on May 31. Looking forwarding to your participation. JP and David. From alexandru.petrescu@gmail.com Fri May 21 13:51:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204823A67C1 for ; Fri, 21 May 2010 13:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.047 X-Spam-Level: X-Spam-Status: No, score=0.047 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_50=0.001, HELO_EQ_FR=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 Qb8Jj9Ge9n8h for ; Fri, 21 May 2010 13:51:36 -0700 (PDT) Received: from smtpfb1-g21.free.fr (smtpfb1-g21.free.fr [212.27.42.9]) by core3.amsl.com (Postfix) with ESMTP id C2CE93A67A4 for ; Fri, 21 May 2010 13:51:31 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by smtpfb1-g21.free.fr (Postfix) with ESMTP id 78D662CA11 for ; Fri, 21 May 2010 22:41:59 +0200 (CEST) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id D4F274B0147 for ; Fri, 21 May 2010 22:41:36 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP for ; Fri, 21 May 2010 22:41:34 +0200 (CEST) Message-ID: <4BF6EFFB.9090607@gmail.com> Date: Fri, 21 May 2010 22:41:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> <039a01caf88d$5b4e5d60$11eb1820$@com> <1274424605.3101.128.camel@d430> <115B81B3-7678-4293-BE38-F35E7ACA2D8D@cisco.com> <1274449810.1673.14.camel@d430> In-Reply-To: <1274449810.1673.14.camel@d430> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100521-1, 21/05/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] whither draft-ietf-roll-protocols-survey-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 20:51:37 -0000 Le 21/05/2010 15:50, Geoff Mulligan a écrit : > WOW. I'll go look - I certainly don't remember this. Was this > decided on the mailing list???? Again, I don't remember any mailing > list discussion. I don't remember such discussion either and I checked archives. > Something like this should not be decided at a IETF meeting (indicted > by your use of the word "minutes"). I think I have never seen a WG item stopped and got rid of. > I think that it is a real shame and mistake that the only document > that is the basis for the decision to invent a new protocol and the > work that went into that document will be lost if it not published. Alex > > Which AD approved this action and again was this published on the > mailing list? I'll go look. > > geoff > > > > > On Fri, 2010-05-21 at 12:25 +0200, JP Vasseur wrote: >> On May 21, 2010, at 8:50 AM, Geoff Mulligan wrote: >> >>> What ever happened to the protocol survey draft? >>> >>> Samita's message about the proliferation of drafts that atrophy >>> got me wondering about the protocol survey draft. This is a >>> working group document and is part of the milestones and charter >>> of the ROLL WG, but this draft has long since expired. >>> >>> It was supposed to be submitted to the IESG as an informational >>> RFC back in Feb 2009. It was last updated in April of 2009 so I >>> would think that it is complete. Why hasn't it been submitted to >>> the IESG? Given that it was THIS document that was the basis for >>> the decision to create a new routing protocol it is important >>> that this information is not lost. >>> >>> Did the WG ever even Last Call this document? >> >> The decision was made not to publish it as an RFC (see WG minutes), >> also in agreement with our AD. >> >> This will be reflected in the Milestone when we will work on them, >> with the WG. >> >> Thanks. >> >> JP. >> >>> >>> geoff >>> >>> >>> _______________________________________________ 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 dominique.barthel@orange-ftgroup.com Fri May 21 13:54:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A73963A6852 for ; Fri, 21 May 2010 13:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.851 X-Spam-Level: *** X-Spam-Status: No, score=3.851 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_FR=0.35, 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 MsOZevCr0g0x for ; Fri, 21 May 2010 13:54:17 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 804573A67C1 for ; Fri, 21 May 2010 13:54:17 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A5EC757C270 for ; Fri, 21 May 2010 22:54:05 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 9B1A857C266 for ; Fri, 21 May 2010 22:54:05 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 22:53:54 +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_01CAF927.B901EA71" Date: Fri, 21 May 2010 22:51:12 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF0143D35C@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Kick metrics out of Objective Functions? Thread-Index: Acr5J1j1zH23jXPZROCdQFnZdneZig== From: To: X-OriginalArrivalTime: 21 May 2010 20:53:54.0341 (UTC) FILETIME=[B96C6550:01CAF927] Subject: [Roll] Kick metrics out of Objective Functions? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 20:54:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF927.B901EA71 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The current situation is that the metrics to be recorded/accumulated are defined in a DIO, while the combination/comparison algorithm to select the best route(s) based on these metrics is described in OF documents. I find this situation suboptimal, for several reasons: * given the variety of LLNs applications out there and there need for complex combined metrics fitted to their application, it seems every system vendor will want to define its own Objective Function, thereby multiplying RFCs and reducing interoperability between devices of different vendors to one OF, namely OF0.=20 * once a network is deployed, the nodes only know a few OFs, those that have been programmed in. A firmware updgrade is required to change the routing behavior beyond that. Given that nodes are going to be deployed for years in the field, I would want RPL to be more flexible at run time.=20 Therefore, I suggest we remove from the OF documents the description of the way the metrics are combined and the best route(s) selected, and provide a flexible model to encode this directly in the DIO, much like we already describe in a DAG Metric container how metrics are accumulated or recorded along a path. Some ideas will be proposed in a later post. Thoughts from the WG ? Best regards Dominique ------_=_NextPart_001_01CAF927.B901EA71 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kick metrics out of Objective Functions?

Dear all,
The current = situation is that the metrics to be recorded/accumulated are defined in = a DIO, while the combination/comparison algorithm to select the best = route(s) based on these metrics is described in OF  documents. I = find this situation suboptimal, for several reasons:

· given the variety of LLNs applications out there and = there need for complex combined metrics fitted to their application, it = seems every system vendor will want to define its own Objective = Function, thereby multiplying RFCs and reducing interoperability between = devices of different vendors to one OF, namely OF0.

· once a network is deployed, the nodes only know a few = OFs, those that have been programmed in. A firmware updgrade is required = to change the routing behavior beyond that. Given that nodes are going = to be deployed for years in the field, I would want RPL to be more = flexible at run time.

Therefore, I suggest = we remove  from the OF documents the description of the way the = metrics are combined and the best route(s) selected, and provide a = flexible model to encode this directly in the DIO, much like we already = describe in a DAG Metric container how metrics are accumulated or = recorded along a path. Some ideas will be proposed in a later = post.

Thoughts from the WG = ?
Best regards
Dominique

------_=_NextPart_001_01CAF927.B901EA71-- From jpv@cisco.com Fri May 21 14:11:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73713A6A39 for ; Fri, 21 May 2010 14:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.247 X-Spam-Level: X-Spam-Status: No, score=-9.247 tagged_above=-999 required=5 tests=[AWL=1.351, 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 Gx31DAGV7UZw for ; Fri, 21 May 2010 14:11:40 -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 5F3313A6A62 for ; Fri, 21 May 2010 14:11:07 -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: AhQHAMOE9ktAZnwN/2dsb2JhbACBP5BAjBVxpHSZW4J1gh0E X-IronPort-AV: E=Sophos;i="4.53,279,1272844800"; d="scan'208,217";a="113579166" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 21 May 2010 20:07:18 +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 o4LK7HC3014214; Fri, 21 May 2010 20:07:18 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 22:07:17 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 22:07:16 +0200 Message-Id: <1611FA43-5C2B-437D-B78A-CADD124DD3F1@cisco.com> From: JP Vasseur To: robert.cragie@gridmerge.com In-Reply-To: <4BF690E6.1030008@gridmerge.com> Content-Type: multipart/alternative; boundary=Apple-Mail-212--187507367 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 21 May 2010 22:07:15 +0200 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> <4BF690E6.1030008@gridmerge.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 May 2010 20:07:17.0046 (UTC) FILETIME=[361B0D60:01CAF921] Cc: ROLL WG Subject: Re: [Roll] Source Routing Header Format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 21:11:42 -0000 --Apple-Mail-212--187507367 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Robert, On May 21, 2010, at 3:55 PM, Robert Cragie wrote: > That's a good point. As far as I know, we got to the point of > specifying some hop-by-hop header containing a specific RPL option > (which I believe Jonathan is working on in 6man) using labels. I > would hope the same underlying principle can be used for both route > record and source routing. Otherwise, we are back to using addresses > in headers. Yes the plan is to have a solution (RH0 like) VERY soon with full address, followed by a label-based solution (to be discussed on the list of course) to optimize. > If this is the case, we really need some way of compressing them for > 6lowpan. > > 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 18/05/2010 5:33 PM, Carsten Bormann wrote: >> >> 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. >> >> Gruesse, Carsten >> >> _______________________________________________ >> 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 --Apple-Mail-212--187507367 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Robert,

On = May 21, 2010, at 3:55 PM, Robert Cragie wrote:

That's a good point. As far as I know, we got to the = point of specifying some hop-by-hop header containing a specific RPL = option (which I believe Jonathan is working on in 6man) using labels. I = would hope the same underlying principle can be used for both route = record and source routing. Otherwise, we are back to using addresses in = headers.

Yes the plan is = to have a solution (RH0 like) VERY soon with full address, followed by a = label-based solution (to be discussed on the list of course) to = optimize.

If this is the case, we really need some way of = compressing them for 6lowpan.

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

<= br>On 18/05/2010 5:33 PM, Carsten Bormann wrote:
On May 18, 2010, at 18:21, Pascal Thubert =
(pthubert) wrote:

  
Then 6LoWPAN can work =
on compressing it using 6LowpAN
techniques.=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.

Gruesse, Carsten

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m=
ailman/listinfo/roll

  =
_______________________________________________
Roll= mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

= --Apple-Mail-212--187507367-- From jpv@cisco.com Fri May 21 23:44:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D279B3A6BB3 for ; Fri, 21 May 2010 23:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.97 X-Spam-Level: X-Spam-Status: No, score=-7.97 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_50=0.001, 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 EUJ9HSOqmQRK for ; Fri, 21 May 2010 23:44: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 C454F3A6B97 for ; Fri, 21 May 2010 23:44:40 -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: AvsEAFoZ90urRN+K/2dsb2JhbACeFXGkcZkshRIE X-IronPort-AV: E=Sophos;i="4.53,282,1272844800"; d="scan'208,217";a="201123593" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 22 May 2010 06:44:34 +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 o4M6iXrS016943; Sat, 22 May 2010 06:44:34 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 May 2010 08:44:32 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 May 2010 08:44:32 +0200 Message-Id: <9FD6C05A-C64E-4B9B-BC14-FD0C7A20A14C@cisco.com> From: JP Vasseur To: "" In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF0143D35C@ftrdmel0.rd.francetelecom.fr> Content-Type: multipart/alternative; boundary=Apple-Mail-218--149272250 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 22 May 2010 08:44:31 +0200 References: <8E09C72DBC577D489F13A71228C0B7BF0143D35C@ftrdmel0.rd.francetelecom.fr> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 May 2010 06:44:32.0430 (UTC) FILETIME=[3C2BA4E0:01CAF97A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17398.005 X-TM-AS-Result: No--24.887900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] Kick metrics out of Objective Functions? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 06:44:41 -0000 --Apple-Mail-218--149272250 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Dominique, On May 21, 2010, at 10:51 PM, = wrote: > Dear all, > The current situation is that the metrics to be recorded/accumulated =20= > are defined in a DIO, while the combination/comparison algorithm to =20= > select the best route(s) based on these metrics is described in OF =20= > documents. I find this situation suboptimal, for several reasons: > > =B7 given the variety of LLNs applications out there and there need =20= > for complex combined metrics fitted to their application, it seems =20 > every system vendor will want to define its own Objective Function, =20= > thereby multiplying RFCs and reducing interoperability between =20 > devices of different vendors to one OF, namely OF0. > > =B7 once a network is deployed, the nodes only know a few OFs, those =20= > that have been programmed in. A firmware updgrade is required to =20 > change the routing behavior beyond that. Given that nodes are going =20= > to be deployed for years in the field, I would want RPL to be more =20 > flexible at run time. > > Therefore, I suggest we remove from the OF documents the =20 > description of the way the metrics are combined and the best =20 > route(s) selected, and provide a flexible model to encode this =20 > directly in the DIO, much like we already describe in a DAG Metric =20 > container how metrics are accumulated or recorded along a path. Some =20= > ideas will be proposed in a later post. > Thanks for your email. I fully agree (in line with the "decoupling =20 metric and OF" email I sent out some time ago). > Thoughts from the WG ? > Best regards > Dominique > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-218--149272250 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi = Dominique,


=

Dear all,
The current situation is that the metrics to = be recorded/accumulated are defined in a DIO, while the = combination/comparison algorithm to select the best route(s) based on = these metrics is described in OF  documents. I find this situation = suboptimal, for several reasons:

=B7 given = the variety of LLNs applications out there and there need for complex = combined metrics fitted to their application, it seems every system = vendor will want to define its own Objective Function, thereby = multiplying RFCs and reducing interoperability between devices of = different vendors to one OF, namely OF0.

=B7 once a = network is deployed, the nodes only know a few OFs, those that have been = programmed in. A firmware updgrade is required to change the routing = behavior beyond that. Given that nodes are going to be deployed for = years in the field, I would want RPL to be more flexible at run = time.

Therefore, I suggest we remove  from the OF = documents the description of the way the metrics are combined and the = best route(s) selected, and provide a flexible model to encode this = directly in the DIO, much like we already describe in a DAG Metric = container how metrics are accumulated or recorded along a path. Some = ideas will be proposed in a later = post.

Thanks for your email. I fully = agree (in line with the "decoupling metric and OF" email I sent out some = time ago).

Thoughts from the WG ?
Best regards =
Dominique

= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-218--149272250-- From jpv@cisco.com Fri May 21 23:46:40 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36A23A6BBC for ; Fri, 21 May 2010 23:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.293 X-Spam-Level: X-Spam-Status: No, score=-9.293 tagged_above=-999 required=5 tests=[AWL=1.305, 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 5m8ELpPES8ul for ; Fri, 21 May 2010 23:46:40 -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 B6DAE3A6B97 for ; Fri, 21 May 2010 23:46:39 -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: AgsFAA8a90tAZnwN/2dsb2JhbACBP5xWcaRjmS6FEgQ X-IronPort-AV: E=Sophos;i="4.53,282,1272844800"; d="scan'208,217";a="113579633" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 May 2010 06:46:32 +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 o4M6kWdG029146 for ; Sat, 22 May 2010 06:46:32 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 May 2010 08:46:32 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 May 2010 08:46:31 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-220--149151759 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 22 May 2010 08:46:31 +0200 References: <20100521205455.GA4425@amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 May 2010 06:46:32.0003 (UTC) FILETIME=[83710930:01CAF97A] Subject: [Roll] Fwd: Mail Flood Last Night Resolved X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 06:46:40 -0000 --Apple-Mail-220--149151759 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: "Glen Barney (AMS)" > Date: May 21, 2010 10:54:55 PM CEDT > To: ietf-announce@ietf.org, ietf@ietf.org > Subject: Mail Flood Last Night Resolved > > All - > > The previously-announced flood of email has been resolved and > cleared, and > all mail has been delivered. Mail flow now appears to be back to > normal, > and we will continue to monitor to ensure that this remains the case. > > Thank you for your patience. > > Glen Barney > IT Director > AMS (IETF Secretariat) --Apple-Mail-220--149151759 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = "Glen Barney (AMS)" <glen@amsl.com>
Date: = May 21, 2010 10:54:55 PM CEDT
Subject: = Mail Flood Last Night Resolved

All = -

The previously-announced flood of email has been resolved and = cleared, and
all mail has been delivered.  Mail flow now appears = to be back to normal,
and we will continue to monitor to ensure that = this remains the case.

Thank you for your patience.

Glen = Barney
IT Director
AMS (IETF = Secretariat)

= --Apple-Mail-220--149151759-- From alexandru.petrescu@gmail.com Sat May 22 03:05:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FBB3A6C52 for ; Sat, 22 May 2010 03:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.058 X-Spam-Level: X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_50=0.001, HELO_EQ_FR=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 Xm-tggrQoOTV for ; Sat, 22 May 2010 03:05:47 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 1D86C3A6C51 for ; Sat, 22 May 2010 03:05:45 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 5BE6B4B0063 for ; Sat, 22 May 2010 12:05:35 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP for ; Sat, 22 May 2010 12:05:34 +0200 (CEST) Message-ID: <4BF7AC6A.6080701@gmail.com> Date: Sat, 22 May 2010 12:05:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> <039a01caf88d$5b4e5d60$11eb1820$@com> <1274424605.3101.128.camel@d430> <115B81B3-7678-4293-BE38-F35E7ACA2D8D@cisco.com> In-Reply-To: <115B81B3-7678-4293-BE38-F35E7ACA2D8D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100522-0, 22/05/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] whither draft-ietf-roll-protocols-survey-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 10:05:48 -0000 Le 21/05/2010 12:25, JP Vasseur a écrit : > > On May 21, 2010, at 8:50 AM, Geoff Mulligan wrote: > >> What ever happened to the protocol survey draft? >> >> Samita's message about the proliferation of drafts that atrophy got me >> wondering about the protocol survey draft. This is a working group >> document and is part of the milestones and charter of the ROLL WG, but >> this draft has long since expired. >> >> It was supposed to be submitted to the IESG as an informational RFC back >> in Feb 2009. It was last updated in April of 2009 so I would think that >> it is complete. Why hasn't it been submitted to the IESG? Given that >> it was THIS document that was the basis for the decision to create a new >> routing protocol it is important that this information is not lost. >> >> Did the WG ever even Last Call this document? > > The decision was made not to publish it as an RFC (see WG minutes), also > in agreement with our AD. I have a disagreement - I disagree to not publish this document. Alex > This will be reflected in the Milestone when we will work on them, with > the WG. > > Thanks. > > JP. > >> >> geoff >> >> >> _______________________________________________ >> 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 alexandru.petrescu@gmail.com Sat May 22 03:07:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56BE33A6C52 for ; Sat, 22 May 2010 03:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.069 X-Spam-Level: X-Spam-Status: No, score=0.069 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_50=0.001, HELO_EQ_FR=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 8uuoMjmCkUnd for ; Sat, 22 May 2010 03:06:59 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 1B55C3A6C39 for ; Sat, 22 May 2010 03:06:57 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 6A8904B0024; Sat, 22 May 2010 12:06:48 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP; Sat, 22 May 2010 12:06:46 +0200 (CEST) Message-ID: <4BF7ACB2.6030406@gmail.com> Date: Sat, 22 May 2010 12:06:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: JP Vasseur References: <6D9687E95918C04A8B30A7D6DA805A3E0142A175@zensys17.zensys.local> <4BF52DB6.8050905@gmail.com> <6F6D0CF1-A454-4591-B5D2-302529D5A861@cisco.com> In-Reply-To: <6F6D0CF1-A454-4591-B5D2-302529D5A861@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100522-0, 22/05/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] RPL Status X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 10:07:00 -0000 Le 21/05/2010 14:37, JP Vasseur a écrit : > Hi Alex, > > Few comments. Last calling the base specification does not imply by all > means that the work is complete, I would have expected to Last Call a document which we believe is almost done. Alex > we have other items in our charter, could be re-chartered according to > the WG's feed-back, etc ... > We were referring to the */base/* RPL specification and for that we have > a ticket opened that helps > us track that the base specification meets the requirements spelled out > in the four requirements > document. For the record, I'll resend the document, that will be updated > after each revision of RPL. > As pointed out by Phil, if we can move forward with P2P I-D that'd be great. > > Thanks. > > JP and David. > > On May 20, 2010, at 2:40 PM, Alexandru Petrescu wrote: > >> Le 19/05/2010 09:39, Anders Brandt a écrit : >>> All, >>> >the plan is still to Last Call RPL before the next IETF >>> I would like to poll the WG on this statement. >>> The home and building requirements are not met by the current RPL draft >>> and we have not even started discussing the P2P ID mechanisms in detail - >>> or frame format modifications for that matter. >>> Does the WG agree that a RPL spec without support for home and building >>> applications is acceptable? >> >> Only in part because of the failure to meet requirements - I disagree >> to pursue RPL towards LC before the next IETF: it is way too early. >> >> We have wide technical misunderstandings about the scope of this >> protocol and its applicability. >> >> Alex >> >>> Thanks, >>> Anders >>> >>> ------------------------------------------------------------------------ >>> *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On >>> Behalf Of *JP Vasseur >>> *Sent:* Tuesday, May 18, 2010 11:48 >>> *To:* roll WG >>> *Subject:* [Roll] RPL Status >>> >>> Dear WG, >>> >>> Here is a quick status. First, we would like to thank the WG again >>> for the continuous effort and lots of fruitful and productive work ! >>> As discussed in Anaheim, the plan is still to Last Call RPL before >>> the next IETF. The plan is to release the next revision of the RPL >>> I-D by end of next week. Rev-08 will address the following: >>> >>> 1) Security section (integrating the work on the security DT) >>> 2) New DAO mechanism (cleaner and more simple), as agreed on the >>> Mailing List >>> 3) Basic source routing => See also companion drafts to be published >>> very soon for (RH-0 like) >>> 4) Updated manageability section >>> 5) DAO ACK >>> 6) Trickle algorithm removed from the core specification (in a >>> separate doc), Examples removed >>> 7) Several Edits, clarifications, ... >>> >>> I had a discussion with David, and the plan is to have the P2P a >>> separate ID (the current RPL specification provides basic P2P, with >>> "advanced" P2P defined in that I-D), with the objective to progress >>> both documents in parallel. >>> >>> */What else ?/* >>> We need to progress a few other documents: >>> 1) Use of the RPL TLV: see draft-hui-6man-rpl-option (6man WG) >>> 2) Source routing header (RH-0 like): to be published soon >>> (Jonathan/David) >>> 3) RPL Variables (ticket #22) >>> 4) ID related to measurement from P2P (if consensus on Mailing list) >>> >>> Looking forward to your comments as soon as rev-08 will be published. >>> >>> Thanks. >>> >>> JP and David. >>> >>> >>> >>> _______________________________________________ >>> 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 gnawali@cs.stanford.edu Sat May 22 09:29:20 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3FD3A6D3C for ; Sat, 22 May 2010 09:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.962 X-Spam-Level: X-Spam-Status: No, score=-2.962 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 0SF5NJk5BFNJ for ; Sat, 22 May 2010 09:29:19 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id C14883A6845 for ; Sat, 22 May 2010 09:29:19 -0700 (PDT) Received: from mail-gy0-f172.google.com ([209.85.160.172]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1OFrZZ-0006zT-0e for roll@ietf.org; Sat, 22 May 2010 09:29:13 -0700 Received: by gyh4 with SMTP id 4so981327gyh.31 for ; Sat, 22 May 2010 09:29:12 -0700 (PDT) Received: by 10.150.66.15 with SMTP id o15mr4313923yba.435.1274545752109; Sat, 22 May 2010 09:29:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.7.7 with HTTP; Sat, 22 May 2010 09:28:52 -0700 (PDT) In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF0143D35C@ftrdmel0.rd.francetelecom.fr> References: <8E09C72DBC577D489F13A71228C0B7BF0143D35C@ftrdmel0.rd.francetelecom.fr> From: Omprakash Gnawali Date: Sat, 22 May 2010 09:28:52 -0700 Message-ID: To: dominique.barthel@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: d1b7ebe10773c68371983edd1a66f504 Cc: roll@ietf.org Subject: Re: [Roll] Kick metrics out of Objective Functions? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 16:29:20 -0000 On Fri, May 21, 2010 at 1:51 PM, wr= ote: > Dear all, > The current situation is that the metrics to be recorded/accumulated are > defined in a DIO, while the combination/comparison algorithm to select th= e > best route(s) based on these metrics is described in OF=A0 documents. I f= ind > this situation suboptimal, for several reasons: > > =B7 given the variety of LLNs applications out there and there need for > complex combined metrics fitted to their application, it seems every syst= em > vendor will want to define its own Objective Function, thereby multiplyin= g > RFCs and reducing interoperability between devices of different vendors t= o > one OF, namely OF0. ... based on the assumption that we will only have one OF defined. This argument is similar to the one we heard a little while ago. We are assuming that we need to cover every imaginable combination of metrics in the OFs. I had asked what these likely combinations are. Do they work? How have they been used? If we have a small number of examples that people have found useful in practice, lets define the OFs. If there are a large number of these, that would be a motivation for working on some of these generalizations. > =B7 once a network is deployed, the nodes only know a few OFs, those that= have > been programmed in. A firmware updgrade is required to change the routing > behavior beyond that. Given that nodes are going to be deployed for years= in > the field, I would want RPL to be more flexible at run time. > > Therefore, I suggest we remove=A0 from the OF documents the description o= f the > way the metrics are combined and the best route(s) selected, and provide = a > flexible model to encode this directly in the DIO, much like we already > describe in a DAG Metric container how metrics are accumulated or recorde= d > along a path. Some ideas will be proposed in a later post. There are many aspects of a metric that are not represented in the metric value. For example, the type of hysteresis and thresholding that results in stable routing for ETX and latency might be completely different although both are just numbers, accumulated over the hops, and the smaller the better. Encoding everything about a metric and how it is to be used in routing would require a much more complex representation of them. But then again, I haven't been convinced by the stated motivation for this generalization. - om_p From pal@cs.stanford.edu Sat May 22 10:39:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C623A6D5D for ; Sat, 22 May 2010 10:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.017 X-Spam-Level: X-Spam-Status: No, score=-5.017 tagged_above=-999 required=5 tests=[AWL=-1.018, 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 JloEPJXt69wn for ; Sat, 22 May 2010 10:39:29 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 545E73A6D33 for ; Sat, 22 May 2010 10:39:29 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OFsfS-0002Wt-48; Sat, 22 May 2010 10:39:22 -0700 In-Reply-To: References: <8E09C72DBC577D489F13A71228C0B7BF0143D35C@ftrdmel0.rd.francetelecom.fr> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5E92E0AD-70D9-4F95-B3EC-7F5DF794D285@cs.stanford.edu> Content-Transfer-Encoding: quoted-printable From: Philip Levis Date: Sat, 22 May 2010 10:39:20 -0700 To: Omprakash Gnawali X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 5c460fe7d3aaafaf78d72307c0bc7e10 Cc: roll@ietf.org Subject: Re: [Roll] Kick metrics out of Objective Functions? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 17:39:30 -0000 On May 22, 2010, at 9:28 AM, Omprakash Gnawali wrote: > On Fri, May 21, 2010 at 1:51 PM, ftgroup.com> wrote: >> Dear all, >> The current situation is that the metrics to be recorded/=20 >> accumulated are >> defined in a DIO, while the combination/comparison algorithm to =20 >> select the >> best route(s) based on these metrics is described in OF =20 >> documents. I find >> this situation suboptimal, for several reasons: >> >> =B7 given the variety of LLNs applications out there and there need = for >> complex combined metrics fitted to their application, it seems =20 >> every system >> vendor will want to define its own Objective Function, thereby =20 >> multiplying >> RFCs and reducing interoperability between devices of different =20 >> vendors to >> one OF, namely OF0. > > ... based on the assumption that we will only have one OF defined. > > This argument is similar to the one we heard a little while ago. We > are assuming that we need to cover every imaginable combination of > metrics in the OFs. I had asked what these likely combinations are. Do > they work? How have they been used? If we have a small number of > examples that people have found useful in practice, lets define the > OFs. If there are a large number of these, that would be a motivation > for working on some of these generalizations. > >> =B7 once a network is deployed, the nodes only know a few OFs, those =20= >> that have >> been programmed in. A firmware updgrade is required to change the =20 >> routing >> behavior beyond that. Given that nodes are going to be deployed =20 >> for years in >> the field, I would want RPL to be more flexible at run time. >> >> Therefore, I suggest we remove from the OF documents the =20 >> description of the >> way the metrics are combined and the best route(s) selected, and =20 >> provide a >> flexible model to encode this directly in the DIO, much like we =20 >> already >> describe in a DAG Metric container how metrics are accumulated or =20 >> recorded >> along a path. Some ideas will be proposed in a later post. > > There are many aspects of a metric that are not represented in the > metric value. For example, the type of hysteresis and thresholding > that results in stable routing for ETX and latency might be completely > different although both are just numbers, accumulated over the hops, > and the smaller the better. Encoding everything about a metric and how > it is to be used in routing would require a much more complex > representation of them. But then again, I haven't been convinced by > the stated motivation for this generalization. I agree. Let's keep things simple. Phil= From jpv@cisco.com Sun May 23 01:52:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAD4F3A6AFA for ; Sun, 23 May 2010 01:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.015 X-Spam-Level: X-Spam-Status: No, score=-8.015 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 7F-LvhWre1BB for ; Sun, 23 May 2010 01:52:22 -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 774A23A6AF5 for ; Sun, 23 May 2010 01:52:22 -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: AvsEAI+J+EtAZnwM/2dsb2JhbACeEXGiOphWhRME X-IronPort-AV: E=Sophos;i="4.53,285,1272844800"; d="scan'208";a="113940200" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 23 May 2010 08:52:14 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4N8qEQK027827; Sun, 23 May 2010 08:52:14 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 23 May 2010 10:52:14 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 23 May 2010 10:52:13 +0200 Message-Id: <40C26EEC-9301-4C71-BDBA-E3073686FCE1@cisco.com> From: JP Vasseur To: Thomas Herbst In-Reply-To: <485AF6ECE8D1954D996771CC49E996FDC0FE2B21@IT-EXMB-01.silverspringnet.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 23 May 2010 10:52:12 +0200 References: <485AF6ECE8D1954D996771CC49E996FDC0FE2B21@IT-EXMB-01.silverspringnet.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 May 2010 08:52:13.0679 (UTC) FILETIME=[3D0B37F0:01CAFA55] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17400.004 X-TM-AS-Result: No--51.653400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: "roll@ietf.org" Subject: Re: [Roll] downward routing? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2010 08:52:24 -0000 Hi Tom, On May 13, 2010, at 1:39 AM, Thomas Herbst wrote: > Haven't seen anything on this for almost a month. > > Is there progress on some flavor of hop-by-hop or source routing > downward from the DAG Root? > > RH0 going once, going twice...? VERY close, stay tuned Jonathan and David are working on an ID to be shared with the WG very soon. Thanks for your feed-back. JP. > > Tom > > ----------------------------------------------------------------------------------------- > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP Vasseur > Sent: Thursday, April 15, 2010 6:01 AM > To: d.sturek@att.net > Cc: roll@ietf.org > Subject: Re: [Roll] Proposal for Source RoutingHeader Format and > SourceRoutingOperations > > Also my reading (again, co-chair hat off). > > On Apr 15, 2010, at 2:48 PM, Don Sturek wrote: > > > Hi Pascal, > > I believe what you wrote below was the majority view on the reflector. > > Don > > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Thursday, April 15, 2010 5:35 AM > To: JP Vasseur; d.sturek@att.net > Cc: roll@ietf.org > Subject: RE: [Roll] Proposal for Source RoutingHeader Format and > SourceRoutingOperations > > Hi JP and all; > > I'm not fully clear what the WG group really wants to do at this > point. I sensed an agreement to endorse something very close to IPv6 > RH0 in the core spec, and provide a separate spec that would enable > labels in the Source route DAO and the hop by hop header. > > Is that a honest reading of the mailing list? > > Pascal > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP Vasseur > Sent: Thursday, April 15, 2010 2:26 PM > To: d.sturek@att.net > Cc: roll@ietf.org > Subject: Re: [Roll] Proposal for Source RoutingHeader Format and > SourceRoutingOperations > > Hi Don, > > On Apr 8, 2010, at 4:59 PM, Don Sturek wrote: > > I think the issue is this: > 1) ROLL cannot meet its charter without source routing > > Absolutely. > > 2) Claiming the feature is now to be addressed in 6LowPAN > seems a bit wrong. ROLL has as its scope MAC/PHYs other than IEEE > 802.15.4. > > You are absolutely right. IPHC is 15.4 specific. This is why the > idea of using a Label a la MPLS would be an interesting approach > IMO. The labe could be locall significant using DAO as a label > distribution mechanism. Completely link layer agnostic. > > JP. > > How are those addressed? > > Don > > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: Thursday, April 08, 2010 7:52 AM > To: d.sturek@att.net > Cc: daniel.gavelle@jennic.com; roll@ietf.org > Subject: Re: [Roll] Proposal for Source Routing Header Format and > SourceRoutingOperations > > Hi Don, > > It's not so much that 6lowpan is concerning itself with source > routing, it is concerning itself with efficient header compression, > which would include IPv6 extension headers such as RH0. Whatever > ends up getting used for source routing needs to be some sort of > IPv6 extension header. Source routing for IPv6 would naturally > contain IPv6 addresses. The question is whether we want to invent > some new extension header specifically for ROLL which uses something > other (i.e. smaller) than IPv6 addresses, e.g. the tag scheme > mentioned. > > I agree, ROLL must accommodate source routing one way or another. > > Robert > Robert Cragie (Pacific Gas & Electric) > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > On 08/04/2010 2:35 PM, Don Sturek wrote: > I can't see why 6LowPAN (and specifically the HC draft) would > concern itself with source routing. > > Surely source routing is a concern of ROLL (and not 6LowPAN). > > I don't see how ROLL completes its charter or addresses its > requirements without adding source routing. > > Don > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of Daniel Gavelle > Sent: Thursday, April 08, 2010 6:12 AM > To: robert.cragie@gridmerge.com > Cc: roll@ietf.org > Subject: Re: [Roll] Proposal for Source Routing Header Format and > SourceRoutingOperations > > Rob, > > I agree that the source routing for the data frames should be done > as part of the 6LowPAN HC. This already has a stateful IPV6 address > compression based on contexts. It should be possible to compress > the addresses down to two bytes per address if IPv6 addresses are > derived from the 16 bit short address are being used in the LowPAN. > > We don't want to hold up the current HC draft that is going through > last call but the work could be done as a new RFC / amendment. > Source routing compression may need a fix for the problem of HC > compression extending beyond the first fragment. > > Doing the work in the 6LowPAN group means that the compression can > easily be used for any source routing protocol, not just ROLL. It > could be done as a compression for the existing R0 routing header. > Maybe this thread needs moving to the 6LowPAN reflector. > > Daniel. > > > Robert Cragie wrote: > > Hi Pascal, > > Source routing should of course use the IPv6 addresses which means a > lot of overhead for certain underlying link layers, e.g. 802.15.4. I > think it is generally cleaner to do the compression at a layer which > may require it only, e.g. define it in the 6lowpan HC. This is then > free to some extent to specify how the compression is done. Although > I doubt this would go down well in the 6lowpan WG... > > The tag scheme would work but it specifically scopes the source > routing to nodes which operate the scheme. This is probably > acceptable practically but doesn't 'smell right' somehow. > > With regard to the original proposal: it is probably necessary to > carry the full source route all the way to at least the penultimate > node and use an index to show the current position in the route for > potential backtrace and error reporting back along the same route > (assuming link symmetry). This is how RH0 works. > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > > On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote: > > Hi Daniel: > > Routers might have multiple interfaces of multiple MAC types. > Internet 0 even has a MAC-less format. > So the result of you proposal, which looks like a great idea in a pure > 802.15.4 world with short addresses, becomes a nightmare to define > in a fully generic fashion. > > OTOH, a locally significant opaque tag in which the parent could > hide a short address of the child - if it cares to do it that way - > looks like a way more acceptable approach > > So it seems to me that you can get what you want as long as we can > make the tag big enough for short addresses. When the tag is too > small to contain what the parent really needs, then the parent will > have to store a state with the full information in memory, and then > place an index of some sort in the tag. > > What do you think? > > Pascal > > > > > -----Original Message----- > From: Popa, Daniel [mailto:Daniel.Popa@itron.com] > Sent: Thursday, April 08, 2010 11:40 AM > To: ROLL WG > Cc: Pascal Thubert (pthubert); JeongGil Ko (John) > Subject: RE: [Roll] Proposal for Source Routing Header Format and > SourceRoutingOperations > > Hi Pascal, John, > > Since source routing explicitly gives forwarding instruction to each > intermediate node, it can make sense to use only (MAC address based) > > > L2 > > > forwarding instead of (IPv6 address based) L3 forwarding. > > This brings two advantages: > - avoid processing each transit packets up to L3. > - use MAC addresses that - in ROLL environment - have inherently > > > shorter > > > length than an IPv6 address. > > Cheers, > Daniel > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > > Of > > > Pascal Thubert (pthubert) > Sent: jeudi 8 avril 2010 11:15 > To: JeongGil Ko (John); ROLL WG > Subject: Re: [Roll] Proposal for Source Routing Header Format and > SourceRoutingOperations > > Hi John: > > IPv6 already has a number of routing headers, in particular RH0, > > > though it is > > > being deprecated for general use in the Internet. > And there are reasons why the fields in RH0/1 are there and we need > to make sure we lose none of that. In particular a RH is > recoverable, and > > > it is > > > easy to spot the consumed entries. > > On top of this our new problems are: > - make sure the RH stays within the RPL network (since it is used > > > downwards > > > that should be doable) > - control the size (that probably means compress) > > Cheers, > > Pascal > > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > > Of > > > JeongGil Ko (John) > Sent: Wednesday, April 07, 2010 10:05 PM > To: ROLL WG > Subject: [Roll] Proposal for Source Routing Header Format and Source > RoutingOperations > > Hi! > > Great to see all this discussions on downwards route establishment! > > > To > > > add > > > one more to the conversations here is a proposal for source routing > > > headers. > > > In non-storing mode (where only the root has individual path > > > information) > > > the root will be attaching a source routing header to the data > > > packet > > > that a > > > source node wants to send to a specific destination. We can always > > > make the > > > header super fancy but in my opinion I think we only need two fields > > > in this > > > header and here it is! Feel free to break the stuff and mangle with > > > it > > > so that it > > > looks great in the specs later on. FYI, this is the format that I am > > > using in my > > > implementations so it does work :) > > 1. Source Routing Header Format > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NEntry (8 bits) | > > > | > > > +-+-+-+-+-+-+-+-+ > > > + > > > | Source Route Entry (128*NEntry bits) > > > | > > > + > > > + > > > | > > > | > > > Figure 1. Proposed Source Routing Header Format; each line is > > > 32 > > > bits:) > > > - NEntry: Indicates the number of 128 bit addresses that the source > > > route > > > entry field is carrying. > > - Source Route Entry: List of 128 bit address that consist the route > > > to the > > > destination. Here, the address of the node that is one hop away from > > > the > > > *destination* comes first. > > 2. Source Routing Packet Operations > > When source routing is initiated at a storing node (e.g., root of > > > the > > > DODAG), > > > the header is attached on the data packet for the entire route > > > (i.e., > > > from > > > next hop node to the destination). This header is positioned in > > > front > > > of the > > > user payload. When the next hop node receives a packet that is not > > > destined > > > to itself AND the network is NOT provisioned to be in 'storing mode' > > > then it > > > checks NEntry to find what the next hop is in the source route > > > entry. > > > Since > > > the 'Source Route Entry' is ordered in 'farthest -> closest' (in > > > terms > > > of hops) > > > order, a node can figure out what the next hop address is with only > > > the > > > NEntry value (since it already knows how big an ipv6 address is). > > > After > > > collecting the next hop node's address, the node erases this address > element from the entry and decreases NEntry by one. This assures > > > that > > > we > > > avoid the overhead of carrying the entire source route throughout > > > the > > > data > > > path. > > The approach itself should be very simple and trivial for everyone > > > to > > > follow. > > > So we can start from here and build on! > > Thanks. > > -John > > ------ > JeongGil Ko (John) > Ph.D. Student > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko > > _______________________________________________ > 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 > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Adrian.Farrel@huawei.com Sun May 23 04:57:08 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002D33A6BA8 for ; Sun, 23 May 2010 04:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.265 X-Spam-Level: X-Spam-Status: No, score=-0.265 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_50=0.001, STOX_REPLY_TYPE=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 leoeq8Y8WDHZ for ; Sun, 23 May 2010 04:57:07 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 1FFB23A6AF0 for ; Sun, 23 May 2010 04:57:07 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2V006U8FV0QT@usaga03-in.huawei.com> for roll@ietf.org; Sun, 23 May 2010 06:57:00 -0500 (CDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2V00G8IFUYDH@usaga03-in.huawei.com> for roll@ietf.org; Sun, 23 May 2010 06:57:00 -0500 (CDT) Date: Sun, 23 May 2010 12:56:50 +0100 From: Adrian Farrel To: roll@ietf.org Message-id: <34A284B9FB574771BA0B1FADAA8ACEE4@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [Roll] Clarification on draft-ietf-roll-protocols-survey X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2010 11:57:08 -0000 In view of the discussion on this document, I thought I should step in and give my opinion and recollections. Geoff originally said: > This is a working group > document and is part of the milestones and charter of the ROLL WG It is true that the document shows as a working group milestone on the charter page. There is, however, no specific charter task that I see for the production of this document. Clearly the document was particularly useful to the working group in reaching its consensus to start work on RPL. The work of the authors and contributors was valuable and by no means a waste of time. The document has served its purpose. When the charter was written and the milestones composed it seemed the logical progression to produce this document. But time has moved on, and events have over-taken the working group. Continuing to spend working group time on the analysis of other protocols and polishing a document that has served its purpose might not be considered as efficient. As Alex points out... > > Last I remember is public discussion in february 2009 - it ended > with a Chair statement intenting to use this draft as a motivation > to recharter and develop new protocol. And, indeed, the recharter took place based on the content of the survey document. It may have been a mistake at that time to not debate the continuation of the document and get the milestones updated. Geoff asks: > Which AD approved this action and again was this published on the > mailing list No AD approval is needed for a working group to not request publication of a draft. I recall discussing this with the working group chairs at various points and agreeing that I would not require the WG to request publication. I should, however, have asked that the milestones be updated accordingly. Alex also says: > I think I have never seen a WG item stopped and got rid of. > Well, this happens. If you search the archives you will see a good > number of I-Ds with their tracker state as "Dead", and you will > be able to find plenty of WG I-Ds that expired over the years and > were never progressed to RFC. Hope this helps. Regards, Adrian From jpv@cisco.com Mon May 24 03:48:07 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F7D3A6B3B for ; Mon, 24 May 2010 03:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.714 X-Spam-Level: X-Spam-Status: No, score=-7.714 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, 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 4Vb7P83Gqajz for ; Mon, 24 May 2010 03:48:05 -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 9FC6E3A6B1A for ; Mon, 24 May 2010 03:48:05 -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: AmsFAAP2+UtAZnwM/2dsb2JhbACBPpxScYgrmxCZP4JkEQaCGASPQw X-IronPort-AV: E=Sophos;i="4.53,291,1272844800"; d="scan'208,217";a="114177478" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 May 2010 10:47:57 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4OAlt7J008279 for ; Mon, 24 May 2010 10:47:57 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 May 2010 12:47:55 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 May 2010 12:47:55 +0200 Message-Id: <9CF3AFED-1B01-4353-BE6C-324086765BE8@cisco.com> From: JP Vasseur To: "roll@ietf.org WG" Content-Type: multipart/alternative; boundary=Apple-Mail-246-38131701 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 May 2010 12:47:54 +0200 References: <2C73F4C7-6C6F-4538-82D9-66B41E29F056@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 May 2010 10:47:55.0612 (UTC) FILETIME=[912BE1C0:01CAFB2E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17402.006 X-TM-AS-Result: No--53.316600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Fwd: Virtual ROLL Working Group - June 16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 10:48:07 -0000 --Apple-Mail-246-38131701 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, Please find the bridge details below: Topic: Roll Virtual WG Meeting Date: Wednesday, June 16, 2010 Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 208 016 618 Password: roll18 ------------------------------------------------------- To join the meeting online(Now from iPhones and other Smartphones too!) ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=140856737&UID=484302782&PW=NYTUxNTcxNWNh 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: roll18 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that appear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:208 016 618 Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial CCP:+14085256800x208016618# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. Thanks. JP and David. Begin forwarded message: > From: JP Vasseur > Date: May 21, 2010 10:19:55 PM CEDT > To: ROLL WG , iesg-secretary@ietf.org > Cc: Adrian Farrel > Subject: [Roll] Virtual ROLL Working Group - June 16 > > Dear WG, > > We would like to announce a Virtual ROLL Working Group meeting > (conference call) on June 16 at 8:00am PDT = 11:00am ET = 5:00pm CET > = 2:00am Japan time for 2 hours. This will help us continue our > progress. The details of the bridge will be provided shortly. > > If you would like to request a slot, please send a request to the > chairs before May 28. The agenda will be published on May 31. > > Looking forwarding to your participation. > > JP and David. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-246-38131701 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = all,


Please find the bridge details = below:

Topic: Roll Virtual WG Meeting 
Date: = Wednesday, June 16, 2010 
Time: 8:00 am, Pacific Daylight Time = (San Francisco, GMT-07:00) 
Meeting Number: 208 016 = 618 
Password: = roll18 

------------------------------------------------------= - 
To join the meeting online(Now from iPhones and other = Smartphones = too!) 
-------------------------------------------------------&nbs= p;
1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D14085= 6737&UID=3D484302782&PW=3DNYTUxNTcxNWNh 
2. If = requested, enter your name and email address. 
3. If a password = is required, enter the meeting password: roll18 
4. Click = "Join". 
5. If the meeting includes a teleconference, follow the = instructions that appear on your = screen. 

-----------------------------------------------------= -- 
To join the audio conference = only 
------------------------------------------------------- = ;
To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access = code. 
Call-in toll-free number (US/Canada): = +1-866-432-9903 
Call-in toll number (US/Canada): = +1-408-525-6800 
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf&n= bsp;

Access code:208 016 618 

Sign up for a free = trial of WebEx 
http://www.webex.com/go/mcemfreetrial 

C= CP:+14085256800x208016618# 

IMPORTANT NOTICE: This WebEx = service includes a feature that allows audio and any documents and other = materials exchanged or viewed during the session to be recorded. By = joining this session, you automatically consent to such recordings. If = you do not consent to the recording, do not join the = session. 

Thanks.

JP and David.

Begin forwarded message:

From: = JP Vasseur <jpv@cisco.com>
Date: = May 21, 2010 10:19:55 PM CEDT
Cc: Adrian Farrel <Adrian.Farrel@huawei.com><= /font>
Subject: [Roll] Virtual ROLL Working Group - = June 16
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-246-38131701-- From trac@tools.ietf.org Mon May 24 07:07:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8613A6C0E for ; Mon, 24 May 2010 07:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.435 X-Spam-Level: X-Spam-Status: No, score=-101.435 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_20=-0.74, 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 c1RFwNoQf9ip for ; Mon, 24 May 2010 07:07:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4DF423A6C0A for ; Mon, 24 May 2010 07:07:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGYJj-0002to-VV; Mon, 24 May 2010 07:07:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Mon, 24 May 2010 14:07:43 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/11#comment:1 Message-ID: <064.c16240632b28395dfcc6b4fd5e4d8d00@tools.ietf.org> References: <055.e0fd4786b2b49cea04ccc878201f7329@tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <055.e0fd4786b2b49cea04ccc878201f7329@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@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: roll@ietf.org Subject: Re: [Roll] [roll] #11: Decision on prefix packing in DAO messages (was: Decision on prefix packing in DIO messages) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:07:52 -0000 #11: Decision on prefix packing in DAO messages --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: enhancement | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Comment(by jpv@…): Title should read "Decision on prefix packing in DAO messages" -- Ticket URL: roll From Chris.Dearlove@baesystems.com Mon May 24 08:21:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CAF73A6A20 for ; Mon, 24 May 2010 08:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.432 X-Spam-Level: X-Spam-Status: No, score=-4.432 tagged_above=-999 required=5 tests=[AWL=-0.433, 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 lI7fsj+Vvs9w for ; Mon, 24 May 2010 08:21:31 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 32A5B3A6AF1 for ; Mon, 24 May 2010 08:21:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,291,1272841200"; d="scan'208";a="66974198" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 24 May 2010 16:21:07 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o4OFL1VP016880; Mon, 24 May 2010 16:21:01 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 May 2010 16:21:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 24 May 2010 16:21:00 +0100 Message-ID: In-Reply-To: <4BF6BDE0.9080106@gridmerge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] whither draft-ietf-roll-protocols-survey-07 Thread-Index: Acr5GzrVLK8A07nzRea+ryaETthokQCOTClg References: <87pr0tz2r1.fsf@kelsey-ws.hq.ember.com> <028401caf6e5$c5592d60$500b8820$@com> <039a01caf88d$5b4e5d60$11eb1820$@com> <1274424605.3101.128.camel@d430><115B81B3-7678-4293-BE38-F35E7ACA2D8D@cisco.com> <4BF6BDE0.9080106@gridmerge.com> From: "Dearlove, Christopher (UK)" To: , "JP Vasseur" X-OriginalArrivalTime: 24 May 2010 15:21:01.0589 (UTC) FILETIME=[B7F98C50:01CAFB54] Cc: roll@ietf.org Subject: Re: [Roll] whither draft-ietf-roll-protocols-survey-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 15:21:38 -0000 Robert Craigie > In all seriousness, this document should not be allowed to disappear > from the process as I think fundamentally some of the assertions made > it in were questionable, to put it mildly. If that is the case (which I'm not commenting on here) surely that would be a reason to let to disappear rather than not. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From jpv@cisco.com Mon May 24 09:24:42 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4980B3A6C11 for ; Mon, 24 May 2010 09:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.009 X-Spam-Level: X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 UQ7ggKsrObxx for ; Mon, 24 May 2010 09:24:41 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 349E03A6848 for ; Mon, 24 May 2010 09:24:41 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMNE+kurR7Ht/2dsb2JhbACeDnGmaZlahRMEj08 X-IronPort-AV: E=Sophos;i="4.53,292,1272844800"; d="scan'208";a="223725703" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 24 May 2010 16:24:33 +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 o4OGOWUj010673; Mon, 24 May 2010 16:24:33 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 May 2010 18:24:32 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 May 2010 18:24:31 +0200 Message-Id: From: JP Vasseur To: Omprakash Gnawali In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 May 2010 18:24:30 +0200 References: <8E09C72DBC577D489F13A71228C0B7BF0143D35C@ftrdmel0.rd.francetelecom.fr> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 May 2010 16:24:31.0969 (UTC) FILETIME=[97236510:01CAFB5D] Cc: roll@ietf.org Subject: Re: [Roll] Kick metrics out of Objective Functions? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 16:24:42 -0000 On May 22, 2010, at 6:28 PM, Omprakash Gnawali wrote: > On Fri, May 21, 2010 at 1:51 PM, = > wrote: >> Dear all, >> The current situation is that the metrics to be recorded/=20 >> accumulated are >> defined in a DIO, while the combination/comparison algorithm to =20 >> select the >> best route(s) based on these metrics is described in OF documents. =20= >> I find >> this situation suboptimal, for several reasons: >> >> =B7 given the variety of LLNs applications out there and there need = for >> complex combined metrics fitted to their application, it seems =20 >> every system >> vendor will want to define its own Objective Function, thereby =20 >> multiplying >> RFCs and reducing interoperability between devices of different =20 >> vendors to >> one OF, namely OF0. > > ... based on the assumption that we will only have one OF defined. > > This argument is similar to the one we heard a little while ago. We > are assuming that we need to cover every imaginable combination of > metrics in the OFs. Not "every" but certainly a few of them and the combination of them =20 can quickly become non negligible. Note that several of the metrics and constraints =20 defined in the metric ID are derived from the requirements documents. > I had asked what these likely combinations are. Do > they work? How have they been used? If we have a small number of > examples that people have found useful in practice, lets define the > OFs. If there are a large number of these, that would be a motivation > for working on some of these generalizations. When defining a new protocol, it is safer to make it as flexible as =20 possible. Since the nature of the metric or the constraint is specified in the metric itself (see =20= metric ID), re-specifying the metric / constraint in the OF reduces flexibility and adds complexity. =20= Bu not encoding the metric/constraint in the OF, and use the routing attributes as =20 specified in the metric-ID, the models increases flexibility, reduces complexity at no cost. Makes =20 sense ? > >> =B7 once a network is deployed, the nodes only know a few OFs, those =20= >> that have >> been programmed in. A firmware updgrade is required to change the =20 >> routing >> behavior beyond that. Given that nodes are going to be deployed for =20= >> years in >> the field, I would want RPL to be more flexible at run time. >> >> Therefore, I suggest we remove from the OF documents the =20 >> description of the >> way the metrics are combined and the best route(s) selected, and =20 >> provide a >> flexible model to encode this directly in the DIO, much like we =20 >> already >> describe in a DAG Metric container how metrics are accumulated or =20 >> recorded >> along a path. Some ideas will be proposed in a later post. > > There are many aspects of a metric that are not represented in the > metric value. For example, the type of hysteresis and thresholding > that results in stable routing for ETX and latency might be completely > different although both are just numbers, accumulated over the hops, > and the smaller the better. Right. Some of these may be implementation specific (when they do not =20= compromise interoperability), others may be specified in the OF for that matter. > Encoding everything about a metric and how > it is to be used in routing would require a much more complex > representation of them. The point is just to not encode the metric and constraint in the OF to =20= provide more flexibility. And again this is already there as metrics are specified =20= in the metric-ID. Would you agree ? Thanks. JP. > But then again, I haven't been convinced by > the stated motivation for this generalization. > > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Mon May 24 09:36:27 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677753A7038 for ; Mon, 24 May 2010 09:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.665 X-Spam-Level: X-Spam-Status: No, score=-4.665 tagged_above=-999 required=5 tests=[AWL=-0.666, 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 RGG3VS7IO9m7 for ; Mon, 24 May 2010 09:36:26 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id D4EB43A6CC5 for ; Mon, 24 May 2010 09:35:17 -0700 (PDT) Received: from dnab4046bc.stanford.edu ([171.64.70.188]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OGacP-0002yv-IS; Mon, 24 May 2010 09:35:10 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: Date: Mon, 24 May 2010 09:35:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E09C72DBC577D489F13A71228C0B7BF0143D35C@ftrdmel0.rd.francetelecom.fr> To: JP Vasseur X-Mailer: Apple Mail (2.1078) X-Scan-Signature: 8577cc8f8d13cb4ae2b02fc82e253015 Cc: roll@ietf.org Subject: Re: [Roll] Kick metrics out of Objective Functions? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 16:36:27 -0000 On May 24, 2010, at 9:24 AM, JP Vasseur wrote: >=20 > On May 22, 2010, at 6:28 PM, Omprakash Gnawali wrote: >=20 >> On Fri, May 21, 2010 at 1:51 PM, = wrote: >>> Dear all, >>> The current situation is that the metrics to be recorded/accumulated = are >>> defined in a DIO, while the combination/comparison algorithm to = select the >>> best route(s) based on these metrics is described in OF documents. = I find >>> this situation suboptimal, for several reasons: >>>=20 >>> =B7 given the variety of LLNs applications out there and there need = for >>> complex combined metrics fitted to their application, it seems every = system >>> vendor will want to define its own Objective Function, thereby = multiplying >>> RFCs and reducing interoperability between devices of different = vendors to >>> one OF, namely OF0. >>=20 >> ... based on the assumption that we will only have one OF defined. >>=20 >> This argument is similar to the one we heard a little while ago. We >> are assuming that we need to cover every imaginable combination of >> metrics in the OFs. >=20 > Not "every" but certainly a few of them and the combination of them = can quickly become > non negligible. Note that several of the metrics and constraints = defined in the metric ID > are derived from the requirements documents. >=20 >> I had asked what these likely combinations are. Do >> they work? How have they been used? If we have a small number of >> examples that people have found useful in practice, lets define the >> OFs. If there are a large number of these, that would be a motivation >> for working on some of these generalizations. >=20 > When defining a new protocol, it is safer to make it as flexible as = possible. Since the nature > of the metric or the constraint is specified in the metric itself (see = metric ID), re-specifying the > metric / constraint in the OF reduces flexibility and adds complexity. = Bu not encoding the > metric/constraint in the OF, and use the routing attributes as = specified in the metric-ID, the > models increases flexibility, reduces complexity at no cost. Makes = sense ? Yes -- but that methodology (which has served the IETF well in other = domains) is problematic here. Flexibility and generality have a cost, in = terms of code size, code complexity, and packet sizes. We have very well = defined use cases; we should design for them and not try to boil the = ocean. Unless you think that we should include a bytecode language for = interpreting new Objective Functions? Phil= From gnawali@cs.stanford.edu Mon May 24 11:18:40 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18A83A71A5 for ; Mon, 24 May 2010 11:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.379 X-Spam-Level: X-Spam-Status: No, score=-3.379 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, 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 qcSraot2jDn6 for ; Mon, 24 May 2010 11:18:39 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 2D18F3A708D for ; Mon, 24 May 2010 11:15:07 -0700 (PDT) Received: from mail-yw0-f171.google.com ([209.85.211.171]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1OGcB1-0001Iy-Bj for roll@ietf.org; Mon, 24 May 2010 11:14:59 -0700 Received: by ywh1 with SMTP id 1so896739ywh.22 for ; Mon, 24 May 2010 11:14:58 -0700 (PDT) Received: by 10.150.255.31 with SMTP id c31mr6577530ybi.196.1274724898482; Mon, 24 May 2010 11:14:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.7.7 with HTTP; Mon, 24 May 2010 11:14:36 -0700 (PDT) In-Reply-To: <20100523213454.86B5C3A681F@core3.amsl.com> References: <20100523213454.86B5C3A681F@core3.amsl.com> From: Omprakash Gnawali Date: Mon, 24 May 2010 11:14:36 -0700 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 Subject: [Roll] Fwd: New Version Notification for draft-gnawali-roll-etxof-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 18:18:40 -0000 Updates - changed some constants to parameters, no default values. - om_p ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Sun, May 23, 2010 at 2:34 PM Subject: New Version Notification for draft-gnawali-roll-etxof-01 To: gnawali@cs.stanford.edu Cc: pal@cs.stanford.edu A new version of I-D, draft-gnawali-roll-etxof-01.txt has been successfully submitted by Omprakash Gnawali and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-gnawali-roll-etxof Revision: =A0 =A0 =A0 =A001 Title: =A0 =A0 =A0 =A0 =A0 The ETX Objective Function for RPL Creation_date: =A0 2010-05-23 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 7 Abstract: The ETX metric of a wireless link is the expected number of transmissions required to successfully transmit and acknowledge a packet on the link. =A0The Routing Protocol for Low Power and Lossy Networks (RPL) allows the use of objective functions to construct routes that optimize or constrain a routing metric on the paths. This specification describes ETXOF, an objective function that minimizes ETX. =A0The RPL path computation using ETXOF results in minimum-ETX paths from the nodes to the DAG roots, i.e., paths that minimize the number of packet transmissions for packet delivery from nodes in the network to the DAG root. The IETF Secretariat. From abr@sdesigns.dk Tue May 25 02:10:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA813A6AA9 for ; Tue, 25 May 2010 02:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_60=1, SARE_MILLIONSOF=0.315] 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 B16Q-REffmlQ for ; Tue, 25 May 2010 02:10:00 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id BD7753A6935 for ; Tue, 25 May 2010 02:09:59 -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: Tue, 25 May 2010 11:09:50 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A18A@zensys17.zensys.local> In-Reply-To: <50C8A61B-8CD8-44A6-9D54-FE7F19827A1C@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 Thread-Index: Acr4QP8v8ZC4v6quRaKTqzNJJnq4XQDpmbfA References: <463402115.12177031274165176659.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E0142A173@zensys17.zensys.local> <50C8A61B-8CD8-44A6-9D54-FE7F19827A1C@cs.stanford.edu> From: "Anders Brandt" To: "Philip Levis" Cc: roll , Emmanuel Baccelli Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 09:10:11 -0000 Hi Phil=20 comments inline Cheers, Anders > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu]=20 > Sent: Thursday, May 20, 2010 19:22 > To: Anders Brandt > Cc: Mukul Goyal; roll; Emmanuel Baccelli > Subject: Re: [Roll] Fwd: New Version Notification=20 > fordraft-dt-roll-p2p-rpl-00 >=20 >=20 > On May 19, 2010, at 12:25 AM, Anders Brandt wrote: >=20 > > hi Phil > >=20 > >> There is extensive empirical evidence that using hopcount is a > > terrible idea. > >=20 > > [Anders] > > That may very well be. I suggest we put that terrible idea=20 > next to the=20 > > extensive evidence that several commercial systems works=20 > _GOOD_ENOUGH_=20 > > with simple hop-count COMBINED with the ability to find=20 > another route=20 > > if there is a substantial number of retransmissions on that=20 > actual route. > > The result is terribly inexpensive chips with radio,=20 > RAM, CPU=20 > > and everything onboard. Consumers want this! >=20 > Sure -- "if there is a substantial number of retransmissions"=20 > is link validation. But I'm not sure I understand the=20 > argument: even though there's a way to avoid NUD and route=20 > rediscovery, we shouldn't use it? Or is the concern that the=20 > link metric constraint might lead to a disconnected graph? I am not sure I understand your question? (maybe my comment below shows why I do not understand...) >=20 > >=20 > >> If the routing metric is hop-count then the LLN will not=20 > work well;=20 > >> you are better off routing up and down the DAG > >=20 > > [Anders] > > With these small nodes, the only DAG information maintained in=20 > > individual nodes is the DODAGID + source routes a few other=20 > nodes that=20 > > the node is supposed to control in some way. Yes, then=20 > there are some=20 > > few nodes which can do a "Turn a lot of nodes off". They will have=20 > > more RAM + non-volatile memory but we SHOULD NOT put that burden on=20 > > all nodes in the network. (sorry for SHOUTING but we should=20 > really not=20 > > ignore the extensive evidence of the successfull deployment of=20 > > millions of these extemely inexpensive chips out there) >=20 > These nodes do not have neighbor sets? How do they join a=20 > DODAG? Does the home and building automation RFC state that a=20 > neighbor set of size 1 is a requirement for RPL? Should it? As Jerry mentioned in another response to this thread, my nodes may hold neighbor information on a few (<10) neighbors. You have suggested that this is some new requirement. I (and Jerry, I guess) would claim that this is covered by the "memory constrained devices" statement. I agree that the home requirements spec does not explicitly state that a node cannot hold link quality information for all potential neighbors. Nevertheless, "memory constrained devices" was intended to convey that message. Thus, most constrained nodes may be able to hold a DODAGID, a few source routes to a default gateway and some source routes to other nodes in the LLN + the few temporary variables required for route discovery/repair. As Jerry also proposed, my customers prefer to use the RAM for their real applications. >=20 > Phil >=20 >=20 >=20 >=20 From Matteo.Paris@ember.com Tue May 25 08:01:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82B1C3A6ACF for ; Tue, 25 May 2010 08:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, 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 GxcamMJ63NAj for ; Tue, 25 May 2010 08:01:53 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 7E5D43A6C09 for ; Tue, 25 May 2010 08:01:53 -0700 (PDT) Received: from [192.168.81.41] ([192.168.81.41]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 May 2010 11:01:44 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 25 May 2010 11:01:42 -0400 To: roll@ietf.org From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 25 May 2010 15:01:44.0595 (UTC) FILETIME=[30C40630:01CAFC1B] Subject: [Roll] RPL option length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 15:01:54 -0000 The RPL option length field is 2 bytes long. I propose we change it to 1 byte. For comparison, the IPv6 and ND option length fields are 1 byte long. Since RPL is being designed for constrained devices, there won't be a need for options bigger than IPv6 and ND options. If you agree, please send a quick +1 to the list in reply so we can move this small matter forward to a ticket. Thanks, Matteo From robert.cragie@gridmerge.com Tue May 25 12:02:59 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E1D3A67D7 for ; Tue, 25 May 2010 12:02:59 -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 3iAFEnRIB3GF for ; Tue, 25 May 2010 12:02:55 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 8AF3A3A690F for ; Tue, 25 May 2010 12:02:51 -0700 (PDT) Received: from client-86-29-245-200.pete.adsl.virginmedia.com ([86.29.245.200] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OGzOf-0008QK-MZ; Tue, 25 May 2010 20:02:38 +0100 Message-ID: <4BFC1ECB.6020100@gridmerge.com> Date: Tue, 25 May 2010 20:02:35 +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: Matteo Paris References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040600050902070400090608" Cc: roll@ietf.org Subject: Re: [Roll] RPL option length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 19:02:59 -0000 This is a cryptographically signed message in MIME format. --------------ms040600050902070400090608 Content-Type: multipart/alternative; boundary="------------030607050802050706060303" This is a multi-part message in MIME format. --------------030607050802050706060303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +1 A couple of points: 1. You may need to change PadN as well to work for 2 or more octets of padding as in RFC2460 (or maybe simply refer to RFC2460) 2. 1 octet length option in IPv6 and ND options are in 8 octet units - are you proposing the same? I would suggest not in this case. 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 25/05/2010 4:01 PM, Matteo Paris wrote: > > The RPL option length field is 2 bytes long. I propose we change it=20 > to 1 byte. For comparison, the IPv6 and ND option length fields are 1 = > byte long. Since RPL is being designed for constrained devices, there = > won't be a need for options bigger than IPv6 and ND options. > > If you agree, please send a quick +1 to the list in reply so we can=20 > move this small matter forward to a ticket. > > Thanks, > Matteo > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------030607050802050706060303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

A couple of points:

  1. You may need to change PadN as well to work for 2 or more octets of padding as in RFC2460 (or maybe simply refer to RFC2460)
  2. 1 octet length option in IPv6 and ND options are in 8 octet units - are you proposing the same? I would suggest not in this case.

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 25/05/2010 4:01 PM, Matteo Paris wrote:

The RPL option length field is 2 bytes long.  I propose we change it= to 1 byte.  For comparison, the IPv6 and ND option length fields are 1 byte long.  Since RPL is being designed for constrained devices, the= re won't be a need for options bigger than IPv6 and ND options.

If you agree, please send a quick +1 to the list in reply so we can move this small matter forward to a ticket.

Thanks,
Matteo
_______________________________________________
Roll mailing list
Roll@= ietf.org
https://www.ietf.org/mailman/listinfo/roll

--------------030607050802050706060303-- --------------ms040600050902070400090608 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 MjUxOTAyMzVaMCMGCSqGSIb3DQEJBDEWBBSuXxmU2svmMQQPYRbJuIygaRr+9zBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAJ56LjWg4ywHHNJGhkeJF+nidqsXAcu7pS8t/08urXw+Zg81dAC/zL55az6YZ28lkPh3 0L2SBhd73XLmwaLQ8zD4kC/GJv1hOk2Nc0ohAxGg/+qXf5+9tUaRmHIHKuP5PFvTXAqqRg0M CgxGVl/LRwA8vR0Nls2iz2wy3Txf0Tp/v+L+mcCPCe8TKcs4I7qqmZSMsWMp9EJZOIGB6xrO 5xo69qV/K/y1b9t687YTO0FBz6defEcDwrXOsadUjJB5jDW8W2J1uQLtUn4NySzOkjCY171h 2yOucHE0YLIPwzgCdK1r5zFijVE91ukSudiyDWcvfmUkOzM1kratDezh/xQAAAAAAAA= --------------ms040600050902070400090608-- From samitac@ipinfusion.com Tue May 25 13:05:39 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7143A6A55 for ; Tue, 25 May 2010 13:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[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 eZAEY2zm0UWp for ; Tue, 25 May 2010 13:05:38 -0700 (PDT) Received: from smtp106.sbc.mail.gq1.yahoo.com (smtp106.sbc.mail.gq1.yahoo.com [67.195.14.109]) by core3.amsl.com (Postfix) with SMTP id 4FF083A6A4F for ; Tue, 25 May 2010 13:05:38 -0700 (PDT) Received: (qmail 10760 invoked from network); 25 May 2010 20:05:27 -0000 Received: from (samitac@65.223.109.250 with login) by smtp106.sbc.mail.gq1.yahoo.com with SMTP; 25 May 2010 13:05:27 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: 4Z1hZrIVM1moxzuDS9VEn1Y9XymSVeU60N6d5SMX.cDscn.v_hszpV_pRh6DJQy3QkTWRQXEtCaoqmg918FhrwpAP1uMZtkHhHjTMuIkaM1.mBBw1fhJ2yhLU.lnwfPYtEBORNVAb1VdK6wYfG9L2DQkz7qegd4E7BAY.hM47gcItmZlTqhNjqE9Y4ESFI8ZGcOsUtrxPQRRhfo9glT6_IJh0HWSeAYiBJUEQXGdd4S8LsFG7Jo_8eaWOT0hzpaPX6mnX6TmAHSrD.iaRijm02e..0bRd.5d X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Matteo Paris'" , References: In-Reply-To: Date: Tue, 25 May 2010 13:05:28 -0700 Message-ID: <014001cafc45$9f2bc7f0$dd8357d0$@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: Acr8GwwN52pfiS6ESPuT3u5/WvBKPQAKojWg Content-Language: en-us Subject: Re: [Roll] RPL option length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 20:05:39 -0000 +1 -Samita > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Matteo Paris > Sent: Tuesday, May 25, 2010 8:02 AM > To: roll@ietf.org > Subject: [Roll] RPL option length > > > The RPL option length field is 2 bytes long. I propose we change it to 1 > byte. For comparison, the IPv6 and ND option length fields are > 1 byte long. Since RPL is being designed for constrained devices, there > won't be a need for options bigger than IPv6 and ND options. > > If you agree, please send a quick +1 to the list in reply so we can move > this small matter forward to a ticket. > > Thanks, > Matteo > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From joakime@sics.se Tue May 25 13:28:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163EE3A6A7D for ; Tue, 25 May 2010 13:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 HFNQtdsoKzUJ for ; Tue, 25 May 2010 13:28:56 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 098123A6A5C for ; Tue, 25 May 2010 13:28:56 -0700 (PDT) Received: from [192.168.1.144] (c-6616e455.013-276-73746f7.cust.bredbandsbolaget.se [85.228.22.102]) (Authenticated sender: joakime@sics.se) by letter.sics.se (Postfix) with ESMTPSA id D2C89400CB; Tue, 25 May 2010 22:28:46 +0200 (CEST) Message-ID: <4BFC32FE.9000005@sics.se> Date: Tue, 25 May 2010 22:28:46 +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: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL option length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 20:28:57 -0000 +1 -- Joakim Matteo Paris skrev 2010-05-25 17:01: > > The RPL option length field is 2 bytes long. I propose we change it to 1 > byte. For comparison, the IPv6 and ND option length fields are 1 byte > long. Since RPL is being designed for constrained devices, there won't > be a need for options bigger than IPv6 and ND options. > > If you agree, please send a quick +1 to the list in reply so we can move > this small matter forward to a ticket. > > Thanks, > Matteo > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From dat@exegin.com Tue May 25 17:39:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45643A6A48 for ; Tue, 25 May 2010 17:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 uI3tOtFaPsKl for ; Tue, 25 May 2010 17:39:01 -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 A91CA3A6BDA for ; Tue, 25 May 2010 15:59:38 -0700 (PDT) Received: by pva18 with SMTP id 18so1651262pva.31 for ; Tue, 25 May 2010 15:59:27 -0700 (PDT) Received: by 10.141.187.4 with SMTP id o4mr5841387rvp.217.1274828367617; Tue, 25 May 2010 15:59:27 -0700 (PDT) Received: from [172.16.1.52] (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id b2sm203282rvn.7.2010.05.25.15.59.26 (version=SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 15:59:27 -0700 (PDT) Message-ID: <4BFC5636.20606@exegin.com> Date: Tue, 25 May 2010 15:59:02 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Matteo Paris References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] RPL option length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 00:39:02 -0000 +1 Matteo Paris wrote: > > The RPL option length field is 2 bytes long. I propose we change it > to 1 byte. For comparison, the IPv6 and ND option length fields are 1 > byte long. Since RPL is being designed for constrained devices, there > won't be a need for options bigger than IPv6 and ND options. > > If you agree, please send a quick +1 to the list in reply so we can > move this small matter forward to a ticket. > > Thanks, > Matteo > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Ruben.Salazar@landisgyr.com Tue May 25 18:47:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C033A677D for ; Tue, 25 May 2010 18:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_63=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 sBY2iS7RGnJ3 for ; Tue, 25 May 2010 18:47:56 -0700 (PDT) Received: from mta2.cellnet.com (mta2.cellnet.com [148.80.254.17]) by core3.amsl.com (Postfix) with ESMTP id 8376C3A65A6 for ; Tue, 25 May 2010 18:47:56 -0700 (PDT) X-ASG-Debug-ID: 1274838467-43eb00260000-BCmCR7 X-Barracuda-URL: http://172.25.128.17:8000/cgi-bin/mark.cgi Received: from livemail.cellnethunt.com (localhost [127.0.0.1]) by mta2.cellnet.com (Spam Firewall) with ESMTP id 55DDC32FCC0 for ; Tue, 25 May 2010 21:47:47 -0400 (EDT) Received: from livemail.cellnethunt.com ([10.1.130.15]) by mta2.cellnet.com with ESMTP id UpsDHBd4jfZrotvX for ; Tue, 25 May 2010 21:47:47 -0400 (EDT) X-ASG-Whitelist: Sender X-ASG-Whitelist: Client Received: from livemail.cellnethunt.com ([10.1.130.105]) by livemail.cellnethunt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 May 2010 21:47:46 -0400 Received: from mail pickup service by livemail.cellnethunt.com with Microsoft SMTPSVC; Tue, 25 May 2010 21:47:47 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-ASG-Orig-Subj: RE: [Roll] RPL option length Date: Tue, 25 May 2010 21:47:46 -0400 Message-ID: <09D9C0631368C244941E610D99FEA710026259D0@usatlsv105.am.bm.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL option length thread-index: Acr8GzhaAFR2QG0cRWCKr4miHuxYtwAQ3P5w References: From: "Salazar, Ruben" To: "Matteo Paris" , X-OriginalArrivalTime: 26 May 2010 01:47:47.0221 (UTC) FILETIME=[71175C50:01CAFC75] X-Barracuda-Connect: UNKNOWN[10.1.130.15] X-Barracuda-Start-Time: 1274838467 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at cellnet.com Subject: Re: [Roll] RPL option length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 01:47:58 -0000 +1 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Matteo Paris Sent: Tuesday, May 25, 2010 11:02 AM To: roll@ietf.org Subject: [Roll] RPL option length The RPL option length field is 2 bytes long. I propose we change it to 1 byte. For comparison, the IPv6 and ND option length fields are 1 byte long. Since RPL is being designed for constrained devices, there won't be a need for options bigger than IPv6 and ND options. If you agree, please send a quick +1 to the list in reply so we can move this small matter forward to a ticket. Thanks, Matteo _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll Ruben Salazar Director of Technology Landis+Gyr Energy Management Solutions Office: +1 678 258 3165 Fax: +1 678 258 1550 Ruben.Salazar@landisgyr.com www.landisgyr.com manage energy better From m.pouillot@watteco.com Tue May 25 23:38:19 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423DF3A67AF for ; Tue, 25 May 2010 23:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=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 LrjpzEinSwKK for ; Tue, 25 May 2010 23:38:18 -0700 (PDT) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 2DD113A686E for ; Tue, 25 May 2010 23:38:17 -0700 (PDT) Received: from [192.168.4.247] ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id ILM40505 for ; Wed, 26 May 2010 08:38:05 +0200 Message-ID: <4BFCC1CA.1050706@watteco.com> Date: Wed, 26 May 2010 08:38:02 +0200 From: Mathieu Pouillot User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] RPL option length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: m.pouillot@watteco.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 06:38:19 -0000 +1 Mathieu Le 25/05/2010 17:01, Matteo Paris a écrit : > > The RPL option length field is 2 bytes long. I propose we change it > to 1 byte. For comparison, the IPv6 and ND option length fields are 1 > byte long. Since RPL is being designed for constrained devices, there > won't be a need for options bigger than IPv6 and ND options. > > If you agree, please send a quick +1 to the list in reply so we can > move this small matter forward to a ticket. > > Thanks, > Matteo > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > -- Mathieu Pouillot R&D Engineer m.pouillot@watteco.com Tel : +33(0)4 98 01 60 05 (Poste 43) Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE - France www.watteco.com From abr@sdesigns.dk Tue May 25 23:45:20 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A513A688C for ; Tue, 25 May 2010 23:45:20 -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 te9ntnU4BhIO for ; Tue, 25 May 2010 23:45:19 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 6F8A13A686D for ; Tue, 25 May 2010 23:45:19 -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, 26 May 2010 08:45:04 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A190@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL option length Thread-Index: Acr8GzP35ZU+cxGYSQeQ55hD23bN8gAg7lcg References: From: "Anders Brandt" To: "Matteo Paris" , Subject: Re: [Roll] RPL option length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 06:45:20 -0000 +1 - Anders=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Matteo Paris > Sent: Tuesday, May 25, 2010 17:02 > To: roll@ietf.org > Subject: [Roll] RPL option length >=20 >=20 > The RPL option length field is 2 bytes long. I propose we=20 > change it to 1 byte. For comparison, the IPv6 and ND option=20 > length fields are > 1 byte long. Since RPL is being designed for constrained=20 > devices, there won't be a need for options bigger than IPv6=20 > and ND options. >=20 > If you agree, please send a quick +1 to the list in reply so=20 > we can move this small matter forward to a ticket. >=20 > Thanks, > Matteo > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From trac@tools.ietf.org Wed May 26 02:52:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98C33A68ED for ; Wed, 26 May 2010 02:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 J3ZLzUYe0TTX for ; Wed, 26 May 2010 02:52:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1350B3A67DA for ; Wed, 26 May 2010 02:52:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OHDHQ-0002bd-NY; Wed, 26 May 2010 02:52:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Wed, 26 May 2010 09:52:04 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/38 Message-ID: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> X-Trac-Ticket-ID: 38 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@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: roll@ietf.org Subject: [Roll] [roll] #38: Decoupling routing metrics/constraints from Objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 09:52:13 -0000 #38: Decoupling routing metrics/constraints from Objective function --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Email for JP Vasseur April 14: Dear all, Just an (important) clarification: as you know, we have defined routing "attributes" in the metric ID to be used as metrics or a constraints. And considering the number of applications for RPL, we will more than likely see a number of combinations of metrics and/or constraints. Should we want to specify an OF each time we want to use of combination of metric/constraint, we would certainly overlflow the RFC editor queue ;-) It would be nice to have a discussion on how we could come up with the limited number of OF, taking out the metric/constraint from the OF semantics. That would greatly simplify the work and still gives us the required flexibility. Thanks. JP. Email from Dominique Barthel on May 21 Dear all, The current situation is that the metrics to be recorded/accumulated are defined in a DIO, while the combination/comparison algorithm to select the best route(s) based on these metrics is described in OF documents. I find this situation suboptimal, for several reasons: · given the variety of LLNs applications out there and there need for complex combined metrics fitted to their application, it seems every system vendor will want to define its own Objective Function, thereby multiplying RFCs and reducing interoperability between devices of different vendors to one OF, namely OF0. · once a network is deployed, the nodes only know a few OFs, those that have been programmed in. A firmware updgrade is required to change the routing behavior beyond that. Given that nodes are going to be deployed for years in the field, I would want RPL to be more flexible at run time. Therefore, I suggest we remove from the OF documents the description of the way the metrics are combined and the best route(s) selected, and provide a flexible model to encode this directly in the DIO, much like we already describe in a DAG Metric container how metrics are accumulated or recorded along a path. Some ideas will be proposed in a later post. Thoughts from the WG ? Best regards Dominique -- Ticket URL: roll From jpv@cisco.com Wed May 26 02:53:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B6F3A68E9 for ; Wed, 26 May 2010 02:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 0WzgHmCcXRJe for ; Wed, 26 May 2010 02:53:27 -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 B3E143A68C7 for ; Wed, 26 May 2010 02:53:27 -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: Am0FANKM/EurRN+K/2dsb2JhbACBPpxdcaYSmXyFEwQ X-IronPort-AV: E=Sophos;i="4.53,303,1272844800"; d="scan'208,217";a="258113806" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 26 May 2010 09:53:18 +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 o4Q9rIxw008597; Wed, 26 May 2010 09:53:18 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 May 2010 11:53:15 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 May 2010 11:53:14 +0200 Message-Id: <66B68E4A-160F-498C-9E19-706010FB6424@cisco.com> From: JP Vasseur To: Joseph Reddy In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-345-207650969 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 26 May 2010 11:53:14 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 May 2010 09:53:15.0369 (UTC) FILETIME=[42D20590:01CAFCB9] Cc: "roll@ietf.org WG" Subject: Re: [Roll] Feedback from ZigBee interop event X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 09:53:28 -0000 --Apple-Mail-345-207650969 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Resending just to make sure that you concerns have been addressed. On May 14, 2010, at 11:24 AM, JP Vasseur wrote: > Hi Joseph, > > First of all, many thanks for the feed-back. I do not think that you =20= > got yet a reply from the WG. So let me open a ticket to make sure =20 > that your issues are addressed in the coming revision of the RPL ID. > > Thanks again, this type of feed-back is quite useful. > > JP. > > On Apr 12, 2010, at 11:20 PM, Reddy, Joseph wrote: > >> >> Hi, >> >> I would like to share some feedback from the recent interop event =20 >> held by the ZigBee Alliance that was attended by several 802.15.4 =20 >> platform vendors. At this event, the main focus was on testing TCP, =20= >> RPL and 6lowpan protocols. >> >> For the RPL protocol, the DAG formation and data transmission "up" =20= >> towards the root were tested successfully among the various =20 >> platforms. In addition to the feedback on the exiting spec ( see =20 >> below ), the main request is to ensure the spec is quickly updated =20= >> with the routing/forwarding for "downwards" paths so we can move =20 >> forward with our testing. >> >> -Regards, Joseph >> >> >> 1. Need clarification on the Rank and DagRank. The root rank has =20 >> value of 1 but not clear if that is just the integer part or not. >> >> 2. In OF0, the values for minRankIncrease and maxRankIncrease take =20= >> value of 256 which cannot be represented in the DoDAG config =20 >> suboption ( which allows only 1 byte ). This needs to be fixed in =20 >> the spec. Also, re-consider if we really need fractional part in =20 >> the rank, it doesn=92t seem to be very useful. >> >> 3. Clarify the IP source address for DIS/DAO packets - should this =20= >> be the link local or global address ( or either ) ? >> >> 4. Need clarification on flowlabel. Currently it is not possible to =20= >> implement as defined ( without layer violations ) since a node will =20= >> need to know if the next hop is the final destination and if the =20 >> previous hop was the originator of the packet=85..current =20 >> implementations have removed flow label validation >> >> 5. Need clarification on the use of the destination prefix. How =20 >> many of them can be included in a DIO ? Is this intended to be the =20= >> prefix of the 6lowpan or is this a prefix that can be reached by =20 >> the root node ( on the wired side ) ? >> >> 6. Does RPL intend to define messages to allow neighboring nodes to =20= >> exchange bidirectional link quality estimates between themselves ? >> >> >> >> >> >> _______________________________________________ >> 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 --Apple-Mail-345-207650969 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Resending just to make sure = that you concerns have been addressed.

On May 14, = 2010, at 11:24 AM, JP Vasseur wrote:

Hi = Joseph,

First of all, many thanks for the feed-back. = I do not think that you got yet a reply from the WG. So let me open a = ticket to make sure that your issues are addressed in the coming = revision of the RPL ID.

Thanks again, this type = of feed-back is quite = useful.

JP.

On Apr 12, = 2010, at 11:20 PM, Reddy, Joseph wrote:

 
Hi,
 
I would like to = share some feedback from the recent interop event held by the ZigBee = Alliance that was attended by several 802.15.4 platform vendors. At this = event, the main focus was on testing TCP, RPL and 6lowpan = protocols.
 
For the RPL protocol, the DAG formation and data = transmission "up" towards the root were tested successfully among the = various platforms. In addition to the feedback on the exiting spec ( see = below ), the main request is to ensure the spec is quickly updated with = the routing/forwarding for "downwards" paths so we can move forward with = our testing.
 
-Regards, = Joseph
 
 
1. Need = clarification on the Rank and DagRank. The root rank has value of 1 but = not clear if that is just the integer part or = not.
 
2. In = OF0, the values for minRankIncrease and maxRankIncrease take value of = 256 which cannot be represented in the DoDAG config suboption ( which = allows only 1 byte ). This needs to be fixed in the spec. Also, re-consider if we really need fractional part in the = rank, it doesn=92t seem to be very useful.
 
3. Clarify the IP source address for = DIS/DAO packets - should this be the link local or global address ( or = either ) ?
 
4. = Need clarification on flowlabel. Currently it is not possible = to implement as = defined ( without layer violations ) since a node will need to = know if the next hop is the final destination and if the previous= hop was = the originator of the packet=85..current implementations have removed flow label = validation
 
5. Need = clarification on = the use of the destination prefix. How = many of them can be included in a DIO ? Is this intended to be = the prefix of the 6lowpan or is this a prefix that can be reached by the = root node ( on the wired side ) ?
 
6. Does RPL intend = to define messages to allow neighboring nodes to exchange bidirectional = link quality estimates between themselves ?
 
 
 
 
 
_____________________________________= __________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-345-207650969-- From jpv@cisco.com Wed May 26 03:00:46 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0D953A68E6 for ; Wed, 26 May 2010 03:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 ONy51Snb5rxO for ; Wed, 26 May 2010 03:00:45 -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 CD8613A6870 for ; Wed, 26 May 2010 03:00:45 -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: AvsEALeO/EtAaMHG/2dsb2JhbACeG3GmEpl7hRME X-IronPort-AV: E=Sophos;i="4.53,303,1272844800"; d="scan'208";a="535410935" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 26 May 2010 10:00:29 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4QA0KZr026342 for ; Wed, 26 May 2010 10:00:28 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 May 2010 12:00:15 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 May 2010 12:00:15 +0200 Message-Id: From: JP Vasseur To: ROLL WG In-Reply-To: <2C73F4C7-6C6F-4538-82D9-66B41E29F056@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 26 May 2010 12:00:14 +0200 References: <2C73F4C7-6C6F-4538-82D9-66B41E29F056@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 May 2010 10:00:15.0278 (UTC) FILETIME=[3D1B0CE0:01CAFCBA] Subject: Re: [Roll] Virtual ROLL Working Group - June 16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 10:00:46 -0000 Just a gentle reminder to let you know that should you want a slot for the Virtual ROLL WG meeting on June 16, please send your request by May 28. Thanks. JP. On May 21, 2010, at 10:19 PM, JP Vasseur wrote: > Dear WG, > > We would like to announce a Virtual ROLL Working Group meeting > (conference call) on June 16 at 8:00am PDT = 11:00am ET = 5:00pm CET > = 2:00am Japan time for 2 hours. This will help us continue our > progress. The details of the bridge will be provided shortly. > > If you would like to request a slot, please send a request to the > chairs before May 28. The agenda will be published on May 31. > > Looking forwarding to your participation. > > JP and David. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From dominique.barthel@orange-ftgroup.com Wed May 26 03:53:20 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751E53A68A3 for ; Wed, 26 May 2010 03:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=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 9mdzgR4cw9qL for ; Wed, 26 May 2010 03:53:19 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 0132F3A68E9 for ; Wed, 26 May 2010 03:53:18 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D5170FC4026; Wed, 26 May 2010 12:44:41 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id B162FFC40C4; Wed, 26 May 2010 12:21:19 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 May 2010 12:19:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 May 2010 12:17:06 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF0143DC12@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Virtual ROLL Working Group - June 16 Thread-Index: Acr8unC2cT0kbB0MQ2CIwIuc1Yb7GwAAT4ZQ References: <2C73F4C7-6C6F-4538-82D9-66B41E29F056@cisco.com> From: To: X-OriginalArrivalTime: 26 May 2010 10:19:51.0754 (UTC) FILETIME=[FA570AA0:01CAFCBC] Subject: Re: [Roll] Virtual ROLL Working Group - June 16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 10:53:20 -0000 Hi JP, Thanks for the reminder. I think the group should have a slot to discuss the combination of = metrics people in the audience anticipate to use for their LLNs, so that = we can make informed decisions in the "OF vs DIO" metrics discussion = (mail thread "Kick metrics out of Objective Functions?"). I do not necessarily need to "own" that slot as long as it's there. Given it's an interim meeting, I take it that no I-D is required to get = a slot? I volunteer to try again to gather the audience opinion before the = meeting so we have a basis for discussion. Best, Dominique -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = JP Vasseur Envoy=E9 : mercredi 26 mai 2010 12:00 =C0 : ROLL WG Objet : Re: [Roll] Virtual ROLL Working Group - June 16 Just a gentle reminder to let you know that should you want a slot for = the Virtual ROLL WG meeting on June 16, please send your request by May = 28. Thanks. JP. On May 21, 2010, at 10:19 PM, JP Vasseur wrote: > Dear WG, > > We would like to announce a Virtual ROLL Working Group meeting =20 > (conference call) on June 16 at 8:00am PDT =3D 11:00am ET =3D 5:00pm = CET =20 > =3D 2:00am Japan time for 2 hours. This will help us continue our =20 > progress. The details of the bridge will be provided shortly. > > If you would like to request a slot, please send a request to the =20 > chairs before May 28. The agenda will be published on May 31. > > Looking forwarding to your participation. > > JP and David. > _______________________________________________ > 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 alexandru.petrescu@gmail.com Wed May 26 05:21:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30ADC3A6804 for ; Wed, 26 May 2010 05:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_FR=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 filEP8b4Mg8t for ; Wed, 26 May 2010 05:21:34 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id E1FB83A68E9 for ; Wed, 26 May 2010 05:21:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o4QCLKP9023831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 May 2010 14:21:20 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o4QCLKJm014561; Wed, 26 May 2010 14:21:20 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o4QCLKb5010642; Wed, 26 May 2010 14:21:20 +0200 Message-ID: <4BFD1240.50906@gmail.com> Date: Wed, 26 May 2010 14:21:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] RPL option length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 12:21:35 -0000 Le 25/05/2010 17:01, Matteo Paris a écrit : > > The RPL option length field is 2 bytes long. I propose we change it to 1 > byte. For comparison, the IPv6 and ND option length fields are 1 byte > long. Since RPL is being designed for constrained devices, there won't > be a need for options bigger than IPv6 and ND options. > > If you agree, please send a quick +1 to the list in reply so we can move > this small matter forward to a ticket. I disagree - should I send a -1? (I can't seem to remember having seen -1 sent to IETF lists, thus I wonder whether the '+' is really necessary). Alex > > Thanks, > Matteo > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From pthubert@cisco.com Wed May 26 06:15:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C43223A6960 for ; Wed, 26 May 2010 06:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[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 MpOhb4FOnB9u for ; Wed, 26 May 2010 06:15:34 -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 703023A698C for ; Wed, 26 May 2010 06:15:19 -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: AvsEALi7/EurR7Hu/2dsb2JhbACeHnGmYJl4hRME X-IronPort-AV: E=Sophos;i="4.53,304,1272844800"; d="scan'208";a="329529348" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 26 May 2010 13:15:10 +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 o4QDEwnQ018689; Wed, 26 May 2010 13:15:10 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); Wed, 26 May 2010 15:15: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, 26 May 2010 15:15:01 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01F967C6@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL option length Thread-Index: Acr8GzUcr+AvD5/6Tgint38kFOpSIQAuWSLg References: From: "Pascal Thubert (pthubert)" To: "Matteo Paris" , X-OriginalArrivalTime: 26 May 2010 13:15:04.0190 (UTC) FILETIME=[743D79E0:01CAFCD5] Subject: Re: [Roll] RPL option length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 13:15:35 -0000 Hi Matteo and all, It seems that we moved to 2 octets sometime in the past for the metrics, but I see a consensus to try and go back to one octet, even if that means splitting that specific option. Related: with 08, we envision to include some RA options in the DIO. That would be at least the RIO and the PIO.=20 - Then comes the question of the SLLA and the MTU options. Do you think we should carry them as well?=20 - And the name space: it makes sense that the RPL options extend the ND namespace if we are to reuse ND options. Would you agree? Cheers, Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Matteo Paris > Sent: Tuesday, May 25, 2010 5:02 PM > To: roll@ietf.org > Subject: [Roll] RPL option length >=20 >=20 > The RPL option length field is 2 bytes long. I propose we change it to 1 byte. > For comparison, the IPv6 and ND option length fields are > 1 byte long. Since RPL is being designed for constrained devices, there won't > be a need for options bigger than IPv6 and ND options. >=20 > If you agree, please send a quick +1 to the list in reply so we can move this > small matter forward to a ticket. >=20 > Thanks, > Matteo > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From joakime@sics.se Wed May 26 07:12:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71E63A6926 for ; Wed, 26 May 2010 07:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 7LyZwKsGhnTj for ; Wed, 26 May 2010 07:12:12 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 516B13A691A for ; Wed, 26 May 2010 07:12:12 -0700 (PDT) Received: from [193.10.67.77] (harr.sics.se [193.10.67.77]) by letter.sics.se (Postfix) with ESMTPS id 6F96540106; Wed, 26 May 2010 16:12:02 +0200 (CEST) Message-ID: <4BFD2C36.7070308@sics.se> Date: Wed, 26 May 2010 16:12:06 +0200 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: <6A2A459175DABE4BB11DE2026AA50A5D01F967C6@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01F967C6@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL option length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 14:12:14 -0000 Pascal Thubert (pthubert) skrev 2010-05-26 15:15: > Hi Matteo and all, > > It seems that we moved to 2 octets sometime in the past for the metrics, > but I see a consensus to try and go back to one octet, even if that > means splitting that specific option. > Related: with 08, we envision to include some RA options in the DIO. > That would be at least the RIO and the PIO. Great! I have recently been trying out mis-using the destination-prefix in DIOs as if they were PIOs with Autoconfig flag set. Works fine (but is a hack) and is a great shortcut for the quite complex "reasoning" that needs to take place for figuring out what prefix the node should use for autoconfig if RPL does not send PIOs in the DIOs. > - Then comes the question of the SLLA and the MTU options. Do you think > we should carry them as well? If we assume that we will not redefine how RA/RS and possibly wants to avoid too much ND messaging the SLLA is another good "shortcut". > - And the name space: it makes sense that the RPL options extend the ND > namespace if we are to reuse ND options. Would you agree? Yes! Best regards, -- Joakim Eriksson, SICS > Cheers, > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Matteo Paris >> Sent: Tuesday, May 25, 2010 5:02 PM >> To: roll@ietf.org >> Subject: [Roll] RPL option length >> >> >> The RPL option length field is 2 bytes long. I propose we change it > to 1 byte. >> For comparison, the IPv6 and ND option length fields are >> 1 byte long. Since RPL is being designed for constrained devices, > there won't >> be a need for options bigger than IPv6 and ND options. >> >> If you agree, please send a quick +1 to the list in reply so we can > move this >> small matter forward to a ticket. >> >> Thanks, >> Matteo >> _______________________________________________ >> 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 -- -- Joakim From mcr@sandelman.ca Wed May 26 08:39:12 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28DB43A66B4 for ; Wed, 26 May 2010 08:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, 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 RDgwrOGXtLX7 for ; Wed, 26 May 2010 08:39:11 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 378413A67F4 for ; Wed, 26 May 2010 08:39:11 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 136AA3470A for ; Wed, 26 May 2010 11:39:02 -0400 (EDT) Received: from marajade.sandelman.ca.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id C2E5E9844C for ; Wed, 26 May 2010 11:38:58 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF0143DC12@ftrdmel0.rd.francetelecom.fr> References: <2C73F4C7-6C6F-4538-82D9-66B41E29F056@cisco.com> <8E09C72DBC577D489F13A71228C0B7BF0143DC12@ftrdmel0.rd.francetelecom.fr> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 26 May 2010 08:05:26 -0400 Message-ID: <31897.1274875526@marajade.sandelman.ca.sandelman.ca> Sender: mcr@sandelman.ca Resent-To: roll@ietf.org Resent-Date: Wed, 26 May 2010 11:38:58 -0400 Resent-Message-ID: <4932.1274888338@marajade.sandelman.ca.sandelman.ca> Resent-From: Michael Richardson Subject: Re: [Roll] Virtual ROLL Working Group - June 16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 15:39:12 -0000 >>>>> "JP" == dominique barthel writes: JP> Just a gentle reminder to let you know that should you want a JP> slot for the Virtual ROLL WG meeting on June 16, please send JP> your request by May 28. JP> Thanks. JP, I do not believe that PIO/RIO in DIO vs ND-over-blackboard issue has been fully put to bed. I would like specifically to hear from a 6lowpan person, and perhaps from Eric Nordmark about this. I'm asking for time from a person with a view different from mine, because I already understand my viewpoint, and it is their point of view I want to understand. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From pal@cs.stanford.edu Wed May 26 09:00:21 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECB4D3A698C for ; Wed, 26 May 2010 09:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[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 79SSa+WkXjek for ; Wed, 26 May 2010 09:00:21 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 3CDD13A6977 for ; Wed, 26 May 2010 09:00:21 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.106]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OHJ1g-0000hK-Cb; Wed, 26 May 2010 09:00:12 -0700 In-Reply-To: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> References: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu> Content-Transfer-Encoding: quoted-printable From: Philip Levis Date: Wed, 26 May 2010 09:00:11 -0700 To: roll@ietf.org X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621 Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraints from Objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 16:00:22 -0000 On May 26, 2010, at 2:52 AM, roll issue tracker wrote: > #38: Decoupling routing metrics/constraints from Objective function > --------------------------------=20 > +------------------------------------------- > Reporter: jpv@=85 | Owner: jpv@=85 > Type: defect | Status: new > Priority: major | Milestone: > Component: rpl | Version: > Severity: Active WG Document | Keywords: > --------------------------------=20 > +------------------------------------------- > Email for JP Vasseur April 14: > > Dear all, > > Just an (important) clarification: as you know, we have defined =20 > routing > "attributes" in the metric ID to be used > as metrics or a constraints. And considering the number of =20 > applications > for RPL, we will more than likely see a > number of combinations of metrics and/or constraints. Should we =20 > want to > specify an OF each time we want to > use of combination of metric/constraint, we would certainly =20 > overlflow the > RFC editor queue ;-) It would be nice > to have a discussion on how we could come up with the limited =20 > number of > OF, taking out the metric/constraint > from the OF semantics. That would greatly simplify the work and still > gives us the required flexibility. I reiterate that I'm not convinced this is a good idea. In this =20 domain, flexibility has a cost, in terms of code size and therefore =20 unit price. Phil= From jpv@cisco.com Wed May 26 09:22:40 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883183A68D7 for ; Wed, 26 May 2010 09:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-4.650, 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 Mw2TYM0pxNfn for ; Wed, 26 May 2010 09:22:39 -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 873D83A67EA for ; Wed, 26 May 2010 09:22:38 -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: Ao0BAMPn/EuQ/uCWe2dsb2JhbACeGBUBARYiBhyoNpoFhRMEj1M X-IronPort-AV: E=Sophos;i="4.53,304,1272844800"; d="scan'208";a="7838307" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 26 May 2010 15:43:25 +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 o4QGMSnj000011; Wed, 26 May 2010 16:22:28 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 May 2010 18:22:28 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 May 2010 18:22:27 +0200 Message-Id: <2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 26 May 2010 18:22:27 +0200 References: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 May 2010 16:22:28.0128 (UTC) FILETIME=[A2264200:01CAFCEF] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraints from Objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 16:22:40 -0000 Hi Phil, Point well taken. Let me try to quickly reiterate the argument and get =20= feed-back from others (this is why I opened a ticket to hear the opinion of others). In the metric-ID, we have defined a set of routing attributes that can =20= be used as constraints and/or metrics, which will be carried in the DAG container object. We currently have =20 the concept of OF that determines a set of rule for DODAG parent selection, ... There are two options: 1) We decide to hard-code the metric/constraint (remember that =20 constrained-based routing is a MUST in the requirement documents) in the OF 2) We keep the decoupling option as defined today in the metric ID. 1) simply means that each time you define a new combination of metric =20= and/or constraint, you must redefine a new OF ! As I was pointed out when we had a discussion, looking at =20 the spectrum of applications we will likely have to define a *number* of OF, with little flexibility in the =20= deployments. Just for the sake of illustration, take one application Smart Grid: if you look at RPL deployment for =20 Smart Metering, Distribution Automation, Home Energy management, you already have at least 3 or 4 OFs since =20 these applications will not use the same metrics and/or constraints (ETX, Delays, battery-operated =20 constraint, ...). Now considering all of the other applications (Industrial, building, home), one can easily see =20 that this won't scale. So the proposal is easy ... just remove the hard coding constraint =20 from the OF definition, and this provides you a much more flexible solution at no cost. Then you will =20 drastically reduce the number of OF to specify. I do not agree with your "Cost" argument. This is in fact most likely =20= the opposite since some devices will have to support multiple instances, thus most likely, multiple OF if you =20 hard code the metric/constraint, thus leading to more cost complexity. Last but not least, you can also have scenarios where you may want to =20= relax constraint. With 1), no need to support multiple OFs, you just remove the constraint. Thoughts from others ? JP. On May 26, 2010, at 6:00 PM, Philip Levis wrote: > > On May 26, 2010, at 2:52 AM, roll issue tracker wrote: > >> #38: Decoupling routing metrics/constraints from Objective function >> --------------------------------=20 >> +------------------------------------------- >> Reporter: jpv@=85 | Owner: jpv@=85 >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------=20 >> +------------------------------------------- >> Email for JP Vasseur April 14: >> >> Dear all, >> >> Just an (important) clarification: as you know, we have defined =20 >> routing >> "attributes" in the metric ID to be used >> as metrics or a constraints. And considering the number of =20 >> applications >> for RPL, we will more than likely see a >> number of combinations of metrics and/or constraints. Should we =20 >> want to >> specify an OF each time we want to >> use of combination of metric/constraint, we would certainly =20 >> overlflow the >> RFC editor queue ;-) It would be nice >> to have a discussion on how we could come up with the limited =20 >> number of >> OF, taking out the metric/constraint >> from the OF semantics. That would greatly simplify the work and still >> gives us the required flexibility. > > I reiterate that I'm not convinced this is a good idea. In this =20 > domain, flexibility has a cost, in terms of code size and therefore =20= > unit price. > > Phil From jreddy@ti.com Wed May 26 23:33:21 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767B83A67B1 for ; Wed, 26 May 2010 23:33:21 -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 ZGC5ps-N9UhE for ; Wed, 26 May 2010 23:33:15 -0700 (PDT) Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by core3.amsl.com (Postfix) with ESMTP id 8689C3A677D for ; Wed, 26 May 2010 23:33:15 -0700 (PDT) Received: from dlep33.itg.ti.com ([157.170.170.112]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id o4R6X5YY002302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 May 2010 01:33:05 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep33.itg.ti.com (8.13.7/8.13.7) with ESMTP id o4R6X4uP011623; Thu, 27 May 2010 01:33:04 -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 o4R6X4a2009107; Thu, 27 May 2010 01:33:04 -0500 (CDT) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee74.ent.ti.com ([157.170.170.8]) with mapi; Thu, 27 May 2010 01:33:04 -0500 From: "Reddy, Joseph" To: JP Vasseur Date: Thu, 27 May 2010 01:33:03 -0500 Thread-Topic: [Roll] Feedback from ZigBee interop event Thread-Index: Acr8uUb1zRI8vTfxThettjm0NvH9ewArSRXw Message-ID: References: <66B68E4A-160F-498C-9E19-706010FB6424@cisco.com> In-Reply-To: <66B68E4A-160F-498C-9E19-706010FB6424@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DE92901D19672647B9ADB0CB4994986504C9FA61AEdlee02enttico_" MIME-Version: 1.0 Cc: "roll@ietf.org WG" Subject: Re: [Roll] Feedback from ZigBee interop event X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 06:33:21 -0000 --_000_DE92901D19672647B9ADB0CB4994986504C9FA61AEdlee02enttico_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks JP ________________________________ From: JP Vasseur [mailto:jpv@cisco.com] Sent: Wednesday, May 26, 2010 2:53 AM To: Reddy, Joseph Cc: roll@ietf.org WG Subject: Re: [Roll] Feedback from ZigBee interop event Resending just to make sure that you concerns have been addressed. On May 14, 2010, at 11:24 AM, JP Vasseur wrote: Hi Joseph, First of all, many thanks for the feed-back. I do not think that you got ye= t a reply from the WG. So let me open a ticket to make sure that your issue= s are addressed in the coming revision of the RPL ID. Thanks again, this type of feed-back is quite useful. JP. On Apr 12, 2010, at 11:20 PM, Reddy, Joseph wrote: Hi, I would like to share some feedback from the recent interop event held by t= he ZigBee Alliance that was attended by several 802.15.4 platform vendors. = At this event, the main focus was on testing TCP, RPL and 6lowpan protocols= . For the RPL protocol, the DAG formation and data transmission "up" towards = the root were tested successfully among the various platforms. In addition = to the feedback on the exiting spec ( see below ), the main request is to e= nsure the spec is quickly updated with the routing/forwarding for "downward= s" paths so we can move forward with our testing. -Regards, Joseph 1. Need clarification on the Rank and DagRank. The root rank has value of 1= but not clear if that is just the integer part or not. 2. In OF0, the values for minRankIncrease and maxRankIncrease take value of= 256 which cannot be represented in the DoDAG config suboption ( which allo= ws only 1 byte ). This needs to be fixed in the spec. Also, re-consider if = we really need fractional part in the rank, it doesn't seem to be very usef= ul. 3. Clarify the IP source address for DIS/DAO packets - should this be the l= ink local or global address ( or either ) ? 4. Need clarification on flowlabel. Currently it is not possible to impleme= nt as defined ( without layer violations ) since a node will need to know i= f the next hop is the final destination and if the previous hop was the ori= ginator of the packet.....current implementations have removed flow label v= alidation 5. Need clarification on the use of the destination prefix. How many of the= m can be included in a DIO ? Is this intended to be the prefix of the 6lowp= an or is this a prefix that can be reached by the root node ( on the wired = side ) ? 6. Does RPL intend to define messages to allow neighboring nodes to exchang= e bidirectional link quality estimates between themselves ? _______________________________________________ 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 --_000_DE92901D19672647B9ADB0CB4994986504C9FA61AEdlee02enttico_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Thanks JP

From: JP Vasseur [mailto:jpv@cisco.com]= =20
Sent: Wednesday, May 26, 2010 2:53 AM
To: Reddy,=20 Joseph
Cc: roll@ietf.org WG
Subject: Re: [Roll] Feedbac= k=20 from ZigBee interop event

Resending just to make sure that you concerns have been addresse= d.

On May 14, 2010, at 11:24 AM, JP Vasseur wrote:
Hi=20 Joseph,

First of all, many thanks for the feed-back. I do not think that you= got=20 yet a reply from the WG. So let me open a ticket to make sure that your i= ssues=20 are addressed in the coming revision of the RPL ID.

Thanks again, this type of feed-back is quite useful.

JP.

On Apr 12, 2010, at 11:20 PM, Reddy, Joseph wrote:
 
Hi,
 
I would like to share some feedback from the recent= =20 interop event held by the ZigBee Alliance that was attended by several= =20 802.15.4 platform vendors. At this event, the main focus was on testing= TCP,=20 RPL and 6lowpan protocols.
 
For the RPL protocol, the DAG formation and data=20 transmission "up" towards the root were tested successfully among the=20 various platforms. In addition to the feedback on the exiting spec ( se= e=20 below ), the main request is to ensure the spec is quickly updated with= the=20 routing/forwarding for "downwards" paths so we can move forward with ou= r=20 testing.
 
-Regards, Joseph
 
 
1. = Need clarification on the Rank and DagRank. The root rank = has=20 value of 1 but not clear if that is just the integer part or=20 not.
 
2. In OF0, t= he values=20 for minRankIncrease and maxRankIncrease take value of 256 which cannot = be=20 represented in the DoDAG config suboption ( which allows only 1 byte ).= This=20 needs to be fixed in the spec. Also, re-consider=20 if we really need fractional part in the rank, it doesn’t = seem to be=20 very useful.
 
3. Clarify the IP s= ource=20 address for DIS/DAO packets - should this be the link local or global=20 address ( or either ) ?
 
4. Need clarifica= tion on=20 flowlabel. Currently it is not possible to implement as defined ( without layer=20 violations ) since a node will need to kn= ow if=20 the next hop is the final destination and if the previous = hop was the originator of the packet…..current implementations have removed flow label=20 validation
 
5. Need=20 clarification on= =20 the = use of=20 the destination prefix. How many = of them=20 can be included in a DIO ? Is this intended to be the= prefix=20 of the 6lowpan or is this a prefix that can be reached by the root node= ( on=20 the wired side ) ?
 
6. Does RPL intend to define messages to allow neig= hboring=20 nodes to exchange bidirectional link quality estimates between themselv= es=20 ?
 
 
 
 
 
____________________________________= ___________
Roll=20 mailing list
Roll@ietf.org
<= A=20 href=3D"https://www.ietf.org/mailman/listinfo/roll">https://www.ietf.or= g/mailman/listinfo/roll

_______________________________________________
Roll=20 mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

--_000_DE92901D19672647B9ADB0CB4994986504C9FA61AEdlee02enttico_-- From jpv@cisco.com Wed May 26 23:43:29 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028F83A684E for ; Wed, 26 May 2010 23:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.654 X-Spam-Level: X-Spam-Status: No, score=-7.654 tagged_above=-999 required=5 tests=[AWL=1.455, BAYES_05=-1.11, 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 GIY1T95EBk5d for ; Wed, 26 May 2010 23:43:27 -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 906FA3A6843 for ; Wed, 26 May 2010 23:43:27 -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: AmwFAF+x/UurRN+K/2dsb2JhbACBP5xncaVkmhiFEwQ X-IronPort-AV: E=Sophos;i="4.53,309,1272844800"; d="scan'208,217";a="535960189" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 27 May 2010 06:43:18 +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 o4R6h5Rf008161; Thu, 27 May 2010 06:43:18 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 May 2010 08:43:12 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 May 2010 08:43:12 +0200 Message-Id: <613064CB-6CC1-4B34-B5DE-A3DE5C7F417F@cisco.com> From: JP Vasseur To: Joseph Reddy , "Pascal Thubert (pthubert)" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-418-282648258 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 May 2010 08:43:11 +0200 References: <66B68E4A-160F-498C-9E19-706010FB6424@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 May 2010 06:43:12.0559 (UTC) FILETIME=[E0A10BF0:01CAFD67] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17408.004 X-TM-AS-Result: No--27.167000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: "roll@ietf.org WG" Subject: Re: [Roll] Feedback from ZigBee interop event X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 06:43:29 -0000 --Apple-Mail-418-282648258 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Pascal, Since you own the ticket, could you reply to the points below ? Thanks. JP. On May 27, 2010, at 8:33 AM, Reddy, Joseph wrote: > > Thanks JP > > From: JP Vasseur [mailto:jpv@cisco.com] > Sent: Wednesday, May 26, 2010 2:53 AM > To: Reddy, Joseph > Cc: roll@ietf.org WG > Subject: Re: [Roll] Feedback from ZigBee interop event > > Resending just to make sure that you concerns have been addressed. > > On May 14, 2010, at 11:24 AM, JP Vasseur wrote: > >> Hi Joseph, >> >> First of all, many thanks for the feed-back. I do not think that =20 >> you got yet a reply from the WG. So let me open a ticket to make =20 >> sure that your issues are addressed in the coming revision of the =20 >> RPL ID. >> >> Thanks again, this type of feed-back is quite useful. >> >> JP. >> >> On Apr 12, 2010, at 11:20 PM, Reddy, Joseph wrote: >> >>> >>> Hi, >>> >>> I would like to share some feedback from the recent interop event =20= >>> held by the ZigBee Alliance that was attended by several 802.15.4 =20= >>> platform vendors. At this event, the main focus was on testing =20 >>> TCP, RPL and 6lowpan protocols. >>> >>> For the RPL protocol, the DAG formation and data transmission "up" =20= >>> towards the root were tested successfully among the various =20 >>> platforms. In addition to the feedback on the exiting spec ( see =20 >>> below ), the main request is to ensure the spec is quickly updated =20= >>> with the routing/forwarding for "downwards" paths so we can move =20 >>> forward with our testing. >>> >>> -Regards, Joseph >>> >>> >>> 1. Need clarification on the Rank and DagRank. The root rank has =20 >>> value of 1 but not clear if that is just the integer part or not. >>> >>> 2. In OF0, the values for minRankIncrease and maxRankIncrease take =20= >>> value of 256 which cannot be represented in the DoDAG config =20 >>> suboption ( which allows only 1 byte ). This needs to be fixed in =20= >>> the spec. Also, re-consider if we really need fractional part in =20 >>> the rank, it doesn=92t seem to be very useful. >>> >>> 3. Clarify the IP source address for DIS/DAO packets - should this =20= >>> be the link local or global address ( or either ) ? >>> >>> 4. Need clarification on flowlabel. Currently it is not possible =20 >>> to implement as defined ( without layer violations ) since a node =20= >>> will need to know if the next hop is the final destination and if =20= >>> the previous hop was the originator of the packet=85..current =20 >>> implementations have removed flow label validation >>> >>> 5. Need clarification on the use of the destination prefix. How =20 >>> many of them can be included in a DIO ? Is this intended to be the =20= >>> prefix of the 6lowpan or is this a prefix that can be reached by =20 >>> the root node ( on the wired side ) ? >>> >>> 6. Does RPL intend to define messages to allow neighboring nodes =20 >>> to exchange bidirectional link quality estimates between =20 >>> themselves ? >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > --Apple-Mail-418-282648258 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
 
Thanks JP

=
From: JP = Vasseur [mailto:jpv@cisco.com] =
Sent: Wednesday, May 26, 2010 2:53 AM
To: Reddy, = Joseph
Cc: roll@ietf.org = WG
Subject: Re: [Roll] Feedback from ZigBee interop = event

Resending just to make sure that = you concerns have been addressed.

On May 14, = 2010, at 11:24 AM, JP Vasseur wrote:

Hi Joseph,

=
First of all, many thanks for the feed-back. I do not think that = you got yet a reply from the WG. So let me open a ticket to make sure = that your issues are addressed in the coming revision of the RPL = ID.

Thanks again, this type of feed-back is = quite useful.

JP.

=
On Apr 12, 2010, at 11:20 PM, Reddy, Joseph wrote:

=
 
=
Hi,
 
I would like to = share some feedback from the recent interop event held by the ZigBee = Alliance that was attended by several 802.15.4 platform vendors. At = this event, the main focus was on testing TCP, RPL and 6lowpan = protocols.
 
=
For the RPL protocol, the DAG formation and data = transmission "up" towards the root were tested successfully among the = various platforms. In addition to the feedback on the exiting spec ( = see below ), the main request is to ensure the spec is quickly = updated with the routing/forwarding for "downwards" paths so we can = move forward with our testing.
 
-Regards, = Joseph
 
=
 
1. Need = clarification on the Rank and DagRank. The root rank has value of 1 = but not clear if that is just the integer part or = not.
 
2. In OF0, the values for minRankIncrease and = maxRankIncrease take value of 256 which cannot be represented in the = DoDAG config suboption ( which allows only 1 byte ). This needs to = be fixed in the spec. Also, re-consider if we really need fractional part in the = rank, it doesn=92t seem to be very useful.
=
 
3. Clarify the IP source = address for DIS/DAO packets - should this be the link local or global = address ( or either ) ?
 
4. Need clarification on flowlabel. Currently it is not = possible to implement as defined ( without layer = violations ) since a node will need to = know if the next hop is the final destination and if the previous= hop was = the originator of the packet=85..current implementations have removed flow label = validation
 
5. Need clarification on the use of = the destination prefix. How = many of them can be included in a DIO ? Is this intended to be = the prefix of the 6lowpan or is this a prefix that can be reached by = the root node ( on the wired side ) ?
 
6. = Does RPL intend to define messages to allow neighboring nodes to = exchange bidirectional link quality estimates between themselves = ?
 
=
 
 
 
 
_____________________________________= __________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll


= --Apple-Mail-418-282648258-- From yoav@yitran.com Thu May 27 02:05:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004103A68B5 for ; Thu, 27 May 2010 02:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 N8j2GxNG6vDG for ; Thu, 27 May 2010 02:05:08 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by core3.amsl.com (Postfix) with SMTP id 7C6453A69B2 for ; Thu, 27 May 2010 02:05:07 -0700 (PDT) Received: from source ([74.125.82.169]) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKS/41uSuMKFueISbov8TPgih6YFCwBNSm@postini.com; Thu, 27 May 2010 02:04:58 PDT Received: by mail-wy0-f169.google.com with SMTP id 40so691500wyb.0 for ; Thu, 27 May 2010 02:04:57 -0700 (PDT) Received: by 10.216.85.7 with SMTP id t7mr421032wee.114.1274951097483; Thu, 27 May 2010 02:04:57 -0700 (PDT) From: Yoav Ben-Yehezkel References: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu> <2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com> In-Reply-To: <2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr876ihNtGT2TRwSm6MNFaDz8P0cgAi8lOw Date: Thu, 27 May 2010 12:04:56 +0300 Message-ID: To: JP Vasseur , Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraints from Objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 09:05:10 -0000 Hi, I agree that whatever we select in the end must not require us to define a new OF per "metric/constraint combination". I agree that if we come up with a small limited set of OFs - that might be simpler to code, but not very flexible or extendible. My current impression is that the decoupling that the metric supports now is highly flexible in this perspective and not that complex. We've had cases where we started off with one metric installed a few thousands of units, only to realize that we didn't think about a few constraints as well. It would have made backwards compatibility issues much easier to handle if our stack was ready to have the constraints further down the road. Best regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Wednesday, May 26, 2010 7:22 PM To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraints from Objective function Hi Phil, Point well taken. Let me try to quickly reiterate the argument and get feed-back from others (this is why I opened a ticket to hear the opinion of others). In the metric-ID, we have defined a set of routing attributes that can be used as constraints and/or metrics, which will be carried in the DAG container object. We currently have the concept of OF that determines a set of rule for DODAG parent selection, ... There are two options: 1) We decide to hard-code the metric/constraint (remember that constrained-based routing is a MUST in the requirement documents) in the OF 2) We keep the decoupling option as defined today in the metric ID. 1) simply means that each time you define a new combination of metric and/or constraint, you must redefine a new OF ! As I was pointed out when we had a discussion, looking at the spectrum of applications we will likely have to define a *number* of OF, with little flexibility in the deployments. Just for the sake of illustration, take one application Smart Grid: if you look at RPL deployment for Smart Metering, Distribution Automation, Home Energy management, you already have at least 3 or 4 OFs since these applications will not use the same metrics and/or constraints (ETX, Delays, battery-operated constraint, ...). Now considering all of the other applications (Industrial, building, home), one can easily see that this won't scale. So the proposal is easy ... just remove the hard coding constraint from the OF definition, and this provides you a much more flexible solution at no cost. Then you will drastically reduce the number of OF to specify. I do not agree with your "Cost" argument. This is in fact most likely the opposite since some devices will have to support multiple instances, thus most likely, multiple OF if you hard code the metric/constraint, thus leading to more cost complexity. Last but not least, you can also have scenarios where you may want to relax constraint. With 1), no need to support multiple OFs, you just remove the constraint. Thoughts from others ? JP. On May 26, 2010, at 6:00 PM, Philip Levis wrote: > > On May 26, 2010, at 2:52 AM, roll issue tracker wrote: > >> #38: Decoupling routing metrics/constraints from Objective function >> -------------------------------- >> +------------------------------------------- >> Reporter: jpv@. | Owner: jpv@. >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: Active WG Document | Keywords: >> -------------------------------- >> +------------------------------------------- >> Email for JP Vasseur April 14: >> >> Dear all, >> >> Just an (important) clarification: as you know, we have defined >> routing >> "attributes" in the metric ID to be used >> as metrics or a constraints. And considering the number of >> applications >> for RPL, we will more than likely see a >> number of combinations of metrics and/or constraints. Should we >> want to >> specify an OF each time we want to >> use of combination of metric/constraint, we would certainly >> overlflow the >> RFC editor queue ;-) It would be nice >> to have a discussion on how we could come up with the limited >> number of >> OF, taking out the metric/constraint >> from the OF semantics. That would greatly simplify the work and still >> gives us the required flexibility. > > I reiterate that I'm not convinced this is a good idea. In this > domain, flexibility has a cost, in terms of code size and therefore > unit price. > > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Thu May 27 02:21:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8653A68B5 for ; Thu, 27 May 2010 02:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 ioPXylpYEBMc for ; Thu, 27 May 2010 02:21:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C3BDF3A6AA0 for ; Thu, 27 May 2010 02:21:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OHZHA-0005H4-P7; Thu, 27 May 2010 02:21:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Thu, 27 May 2010 09:21:16 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/39 Message-ID: <055.f20158b4ed882efacedace4b6140209d@tools.ietf.org> X-Trac-Ticket-ID: 39 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@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: roll@ietf.org Subject: [Roll] [roll] #39: RPL option lenght X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 09:21:50 -0000 #39: RPL option lenght --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Matteo Paris >> Sent: Tuesday, May 25, 2010 5:02 PM >> To: roll@ietf.org >> Subject: [Roll] RPL option length >> >> >> The RPL option length field is 2 bytes long. I propose we change it > to 1 byte. >> For comparison, the IPv6 and ND option length fields are >> 1 byte long. Since RPL is being designed for constrained devices, > there won't >> be a need for options bigger than IPv6 and ND options. >> >> If you agree, please send a quick +1 to the list in reply so we can > move this >> small matter forward to a ticket. >> >> Thanks, >> Matteo -- Ticket URL: roll From pthubert@cisco.com Thu May 27 02:28:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1411D3A68DE for ; Thu, 27 May 2010 02:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=-4.555, 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 WKNWWVqm08u1 for ; Thu, 27 May 2010 02:28:47 -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 61E8D3A68B5 for ; Thu, 27 May 2010 02:28:46 -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: AjICAP7X/UuQ/uCWe2dsb2JhbACeGBUBARYiBhymBJoWhRME X-IronPort-AV: E=Sophos;i="4.53,310,1272844800"; d="scan'208";a="7887233" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 27 May 2010 08:49:29 +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 o4R9Saij018306; Thu, 27 May 2010 09:28:36 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, 27 May 2010 11:28:35 +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, 27 May 2010 11:28:32 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01F96BE1@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #38: Decoupling routing metrics/constraints fromObjective function Thread-Index: Acr876ihNtGT2TRwSm6MNFaDz8P0cgAi8lOwAACyYcA= References: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu><2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com> From: "Pascal Thubert (pthubert)" To: "Yoav Ben-Yehezkel" , X-OriginalArrivalTime: 27 May 2010 09:28:35.0995 (UTC) FILETIME=[FB7536B0:01CAFD7E] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraints fromObjective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 09:28:48 -0000 Hi Yoav and Dominique: I agree with you all that we need to decouple. In my mind image, the OF ties the result of the metric computation with some other policies that implement the objective. If we need some logic to play with the metrics themselves in order to figure out something scalar off them, that should come with the metrics, like having a metrics function in parallel to the objective function. So, would you need a code for that metric function? Would that be in the metric draft then? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Yoav Ben-Yehezkel > Sent: Thursday, May 27, 2010 11:05 AM > To: JP Vasseur; Philip Levis > Cc: roll@ietf.org > Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraints > fromObjective function >=20 > Hi, >=20 > I agree that whatever we select in the end must not require us to define a > new OF per "metric/constraint combination". >=20 > I agree that if we come up with a small limited set of OFs - that might be > simpler to code, but not very flexible or extendible. My current impression is > that the decoupling that the metric supports now is highly flexible in this > perspective and not that complex. >=20 > We've had cases where we started off with one metric installed a few > thousands of units, only to realize that we didn't think about a few > constraints as well. It would have made backwards compatibility issues much > easier to handle if our stack was ready to have the constraints further down > the road. >=20 > Best regards, > Yoav >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP > Vasseur > Sent: Wednesday, May 26, 2010 7:22 PM > To: Philip Levis > Cc: roll@ietf.org > Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraints from > Objective function >=20 > Hi Phil, >=20 > Point well taken. Let me try to quickly reiterate the argument and get feed- > back from others (this is why I opened a ticket to hear the opinion of others). >=20 > In the metric-ID, we have defined a set of routing attributes that can be used > as constraints and/or metrics, which will be carried in the DAG container > object. We currently have the concept of OF that determines a set of rule for > DODAG parent selection, ... >=20 > There are two options: > 1) We decide to hard-code the metric/constraint (remember that > constrained-based routing is a MUST in the requirement documents) in the > OF > 2) We keep the decoupling option as defined today in the metric ID. >=20 > 1) simply means that each time you define a new combination of metric > and/or constraint, you must redefine a new OF ! As I was pointed out when > we had a discussion, looking at the spectrum of applications we will likely > have to define a *number* of OF, with little flexibility in the deployments. > Just for the sake of illustration, take one application Smart Grid: if you look at > RPL deployment for Smart Metering, Distribution Automation, Home Energy > management, you already have at least 3 or 4 OFs since these applications > will not use the same metrics and/or constraints (ETX, Delays, battery- > operated constraint, ...). Now considering all of the other applications > (Industrial, building, home), one can easily see that this won't scale. >=20 > So the proposal is easy ... just remove the hard coding constraint from the OF > definition, and this provides you a much more flexible solution at no cost. > Then you will drastically reduce the number of OF to specify. >=20 >=20 > I do not agree with your "Cost" argument. This is in fact most likely the > opposite since some devices will have to support multiple instances, thus > most likely, multiple OF if you hard code the metric/constraint, thus leading > to more cost complexity. >=20 > Last but not least, you can also have scenarios where you may want to relax > constraint. With 1), no need to support multiple OFs, you just remove the > constraint. >=20 > Thoughts from others ? >=20 > JP. >=20 >=20 > On May 26, 2010, at 6:00 PM, Philip Levis wrote: >=20 > > > > On May 26, 2010, at 2:52 AM, roll issue tracker wrote: > > > >> #38: Decoupling routing metrics/constraints from Objective function > >> -------------------------------- > >> +------------------------------------------- > >> Reporter: jpv@. | Owner: jpv@. > >> Type: defect | Status: new > >> Priority: major | Milestone: > >> Component: rpl | Version: > >> Severity: Active WG Document | Keywords: > >> -------------------------------- > >> +------------------------------------------- > >> Email for JP Vasseur April 14: > >> > >> Dear all, > >> > >> Just an (important) clarification: as you know, we have defined > >> routing "attributes" in the metric ID to be used as metrics or a > >> constraints. And considering the number of applications for RPL, we > >> will more than likely see a number of combinations of metrics and/or > >> constraints. Should we want to specify an OF each time we want to use > >> of combination of metric/constraint, we would certainly overlflow the > >> RFC editor queue ;-) It would be nice to have a discussion on how we > >> could come up with the limited number of OF, taking out the > >> metric/constraint from the OF semantics. That would greatly simplify > >> the work and still gives us the required flexibility. > > > > I reiterate that I'm not convinced this is a good idea. In this > > domain, flexibility has a cost, in terms of code size and therefore > > unit price. > > > > Phil >=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 From jpv@cisco.com Thu May 27 02:37:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1EF3A68AB for ; Thu, 27 May 2010 02:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.763 X-Spam-Level: X-Spam-Status: No, score=-8.763 tagged_above=-999 required=5 tests=[AWL=1.836, 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 PCHeBPSOTjm6 for ; Thu, 27 May 2010 02:37:55 -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 B6D7C3A6A3F for ; Thu, 27 May 2010 02:37:54 -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: AjICAO3Z/UuQ/uCWe2dsb2JhbACeGBUBARYiBhymC5oWhRME X-IronPort-AV: E=Sophos;i="4.53,310,1272844800"; d="scan'208";a="61888723" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 May 2010 09:37:44 +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 o4R9biCM021708; Thu, 27 May 2010 09:37:44 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 May 2010 11:37:43 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 May 2010 11:37:42 +0200 Message-Id: From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01F96BE1@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 May 2010 11:37:41 +0200 References: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu><2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D01F96BE1@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 May 2010 09:37:43.0070 (UTC) FILETIME=[418A3BE0:01CAFD80] Cc: "roll@ietf.org WG" Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraints fromObjective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 09:37:57 -0000 On May 27, 2010, at 11:28 AM, Pascal Thubert (pthubert) wrote: > Hi Yoav and Dominique: > > I agree with you all that we need to decouple. In my mind image, the > OF > ties the result of the metric computation with some other policies > that > implement the objective. yes > If we need some logic to play with the metrics themselves in order to > figure out something scalar off them, that should come with the > metrics, > like having a metrics function in parallel to the objective function. > So, would you need a code for that metric function? Would that be in > the > metric draft then? if for example, you need to come with a polynomial function of multiple metrics (this was a suggestion from Dominique some time ago), this would indeed be an object in the metric-ID. For the time being, we already have the flexibility to add metrics/constraints (and indicate their nature) in the ID jP. > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Yoav Ben-Yehezkel >> Sent: Thursday, May 27, 2010 11:05 AM >> To: JP Vasseur; Philip Levis >> Cc: roll@ietf.org >> Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/ >> constraints >> fromObjective function >> >> Hi, >> >> I agree that whatever we select in the end must not require us to > define a >> new OF per "metric/constraint combination". >> >> I agree that if we come up with a small limited set of OFs - that > might be >> simpler to code, but not very flexible or extendible. My current > impression is >> that the decoupling that the metric supports now is highly flexible >> in > this >> perspective and not that complex. >> >> We've had cases where we started off with one metric installed a few >> thousands of units, only to realize that we didn't think about a few >> constraints as well. It would have made backwards compatibility >> issues > much >> easier to handle if our stack was ready to have the constraints > further down >> the road. >> >> Best regards, >> Yoav >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP >> Vasseur >> Sent: Wednesday, May 26, 2010 7:22 PM >> To: Philip Levis >> Cc: roll@ietf.org >> Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/ >> constraints > from >> Objective function >> >> Hi Phil, >> >> Point well taken. Let me try to quickly reiterate the argument and >> get > feed- >> back from others (this is why I opened a ticket to hear the opinion >> of > others). >> >> In the metric-ID, we have defined a set of routing attributes that >> can > be used >> as constraints and/or metrics, which will be carried in the DAG > container >> object. We currently have the concept of OF that determines a set of > rule for >> DODAG parent selection, ... >> >> There are two options: >> 1) We decide to hard-code the metric/constraint (remember that >> constrained-based routing is a MUST in the requirement documents) in > the >> OF >> 2) We keep the decoupling option as defined today in the metric ID. >> >> 1) simply means that each time you define a new combination of metric >> and/or constraint, you must redefine a new OF ! As I was pointed out > when >> we had a discussion, looking at the spectrum of applications we will > likely >> have to define a *number* of OF, with little flexibility in the > deployments. >> Just for the sake of illustration, take one application Smart Grid: >> if > you look at >> RPL deployment for Smart Metering, Distribution Automation, Home > Energy >> management, you already have at least 3 or 4 OFs since these > applications >> will not use the same metrics and/or constraints (ETX, Delays, > battery- >> operated constraint, ...). Now considering all of the other > applications >> (Industrial, building, home), one can easily see that this won't > scale. >> >> So the proposal is easy ... just remove the hard coding constraint > from the OF >> definition, and this provides you a much more flexible solution at no > cost. >> Then you will drastically reduce the number of OF to specify. >> >> >> I do not agree with your "Cost" argument. This is in fact most likely > the >> opposite since some devices will have to support multiple instances, > thus >> most likely, multiple OF if you hard code the metric/constraint, thus > leading >> to more cost complexity. >> >> Last but not least, you can also have scenarios where you may want to > relax >> constraint. With 1), no need to support multiple OFs, you just remove > the >> constraint. >> >> Thoughts from others ? >> >> JP. >> >> >> On May 26, 2010, at 6:00 PM, Philip Levis wrote: >> >>> >>> On May 26, 2010, at 2:52 AM, roll issue tracker wrote: >>> >>>> #38: Decoupling routing metrics/constraints from Objective function >>>> -------------------------------- >>>> +------------------------------------------- >>>> Reporter: jpv@. | Owner: jpv@. >>>> Type: defect | Status: new >>>> Priority: major | Milestone: >>>> Component: rpl | Version: >>>> Severity: Active WG Document | Keywords: >>>> -------------------------------- >>>> +------------------------------------------- >>>> Email for JP Vasseur April 14: >>>> >>>> Dear all, >>>> >>>> Just an (important) clarification: as you know, we have defined >>>> routing "attributes" in the metric ID to be used as metrics or a >>>> constraints. And considering the number of applications for RPL, we >>>> will more than likely see a number of combinations of metrics > and/or >>>> constraints. Should we want to specify an OF each time we want to > use >>>> of combination of metric/constraint, we would certainly overlflow > the >>>> RFC editor queue ;-) It would be nice to have a discussion on how > we >>>> could come up with the limited number of OF, taking out the >>>> metric/constraint from the OF semantics. That would greatly > simplify >>>> the work and still gives us the required flexibility. >>> >>> I reiterate that I'm not convinced this is a good idea. In this >>> domain, flexibility has a cost, in terms of code size and therefore >>> unit price. >>> >>> Phil >> >> _______________________________________________ >> 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 mdurvy@cisco.com Thu May 27 05:27:55 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9771F3A6ACF for ; Thu, 27 May 2010 05:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[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 d5EC38owBtR7 for ; Thu, 27 May 2010 05:27:54 -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 517FC3A6AC3 for ; Thu, 27 May 2010 05:27:54 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4235 X-IronPort-AV: E=Sophos;i="4.53,311,1272844800"; d="p7s'?scan'208";a="135830613" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 27 May 2010 12:27:45 +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 o4RCRiwr007490; Thu, 27 May 2010 12:27:44 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); Thu, 27 May 2010 14:27:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 May 2010 14:27:42 +0200 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0090_01CAFDA8.C4594C00"; protocol="application/x-pkcs7-signature" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0225E393@XMB-AMS-103.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #38: Decoupling routing metrics/constraintsfromObjective function Thread-Index: Acr9gEjwojrdkqj3Sru3lsFkfXmXvwAFKdlg References: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu><2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D01F96BE1@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "JP Vasseur" , "Pascal Thubert (pthubert)" X-OriginalArrivalTime: 27 May 2010 12:27:43.0677 (UTC) FILETIME=[019356D0:01CAFD98] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraintsfromObjective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 12:27:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0090_01CAFDA8.C4594C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi JP, Pascal, I like the idea of decoupling things, however I'm not quite sure to understand how it would work. Does it mean that there is no OCP object carried by the DIO, only metric/constraint objects which include how to use them? If this is the case how do you assess that you support the OCP? How do you know which objective function to call when you receive a DIO? In short how does this decoupling affect the DIO processing. (right now, in our implementation when a node receives a DIO, it simply looks at the ocp and based on this value it calls the corresponding objective function (an actual C function) to order the potential parent with respect to the existing ones) Best, Mathilde -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: jeudi, 27. mai 2010 11:38 To: Pascal Thubert (pthubert) Cc: roll@ietf.org WG Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraintsfromObjective function On May 27, 2010, at 11:28 AM, Pascal Thubert (pthubert) wrote: > Hi Yoav and Dominique: > > I agree with you all that we need to decouple. In my mind image, the > OF ties the result of the metric computation with some other policies > that implement the objective. yes > If we need some logic to play with the metrics themselves in order to > figure out something scalar off them, that should come with the > metrics, like having a metrics function in parallel to the objective > function. > So, would you need a code for that metric function? Would that be in > the metric draft then? if for example, you need to come with a polynomial function of multiple metrics (this was a suggestion from Dominique some time ago), this would indeed be an object in the metric-ID. For the time being, we already have the flexibility to add metrics/constraints (and indicate their nature) in the ID jP. > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Yoav Ben-Yehezkel >> Sent: Thursday, May 27, 2010 11:05 AM >> To: JP Vasseur; Philip Levis >> Cc: roll@ietf.org >> Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/ >> constraints fromObjective function >> >> Hi, >> >> I agree that whatever we select in the end must not require us to > define a >> new OF per "metric/constraint combination". >> >> I agree that if we come up with a small limited set of OFs - that > might be >> simpler to code, but not very flexible or extendible. My current > impression is >> that the decoupling that the metric supports now is highly flexible >> in > this >> perspective and not that complex. >> >> We've had cases where we started off with one metric installed a few >> thousands of units, only to realize that we didn't think about a few >> constraints as well. It would have made backwards compatibility >> issues > much >> easier to handle if our stack was ready to have the constraints > further down >> the road. >> >> Best regards, >> Yoav >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP >> Vasseur >> Sent: Wednesday, May 26, 2010 7:22 PM >> To: Philip Levis >> Cc: roll@ietf.org >> Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/ >> constraints > from >> Objective function >> >> Hi Phil, >> >> Point well taken. Let me try to quickly reiterate the argument and >> get > feed- >> back from others (this is why I opened a ticket to hear the opinion >> of > others). >> >> In the metric-ID, we have defined a set of routing attributes that >> can > be used >> as constraints and/or metrics, which will be carried in the DAG > container >> object. We currently have the concept of OF that determines a set of > rule for >> DODAG parent selection, ... >> >> There are two options: >> 1) We decide to hard-code the metric/constraint (remember that >> constrained-based routing is a MUST in the requirement documents) in > the >> OF >> 2) We keep the decoupling option as defined today in the metric ID. >> >> 1) simply means that each time you define a new combination of metric >> and/or constraint, you must redefine a new OF ! As I was pointed out > when >> we had a discussion, looking at the spectrum of applications we will > likely >> have to define a *number* of OF, with little flexibility in the > deployments. >> Just for the sake of illustration, take one application Smart Grid: >> if > you look at >> RPL deployment for Smart Metering, Distribution Automation, Home > Energy >> management, you already have at least 3 or 4 OFs since these > applications >> will not use the same metrics and/or constraints (ETX, Delays, > battery- >> operated constraint, ...). Now considering all of the other > applications >> (Industrial, building, home), one can easily see that this won't > scale. >> >> So the proposal is easy ... just remove the hard coding constraint > from the OF >> definition, and this provides you a much more flexible solution at no > cost. >> Then you will drastically reduce the number of OF to specify. >> >> >> I do not agree with your "Cost" argument. This is in fact most likely > the >> opposite since some devices will have to support multiple instances, > thus >> most likely, multiple OF if you hard code the metric/constraint, thus > leading >> to more cost complexity. >> >> Last but not least, you can also have scenarios where you may want to > relax >> constraint. With 1), no need to support multiple OFs, you just remove > the >> constraint. >> >> Thoughts from others ? >> >> JP. >> >> >> On May 26, 2010, at 6:00 PM, Philip Levis wrote: >> >>> >>> On May 26, 2010, at 2:52 AM, roll issue tracker wrote: >>> >>>> #38: Decoupling routing metrics/constraints from Objective function >>>> -------------------------------- >>>> +------------------------------------------- >>>> Reporter: jpv@. | Owner: jpv@. >>>> Type: defect | Status: new >>>> Priority: major | Milestone: >>>> Component: rpl | Version: >>>> Severity: Active WG Document | Keywords: >>>> -------------------------------- >>>> +------------------------------------------- >>>> Email for JP Vasseur April 14: >>>> >>>> Dear all, >>>> >>>> Just an (important) clarification: as you know, we have defined >>>> routing "attributes" in the metric ID to be used as metrics or a >>>> constraints. And considering the number of applications for RPL, we >>>> will more than likely see a number of combinations of metrics > and/or >>>> constraints. Should we want to specify an OF each time we want to > use >>>> of combination of metric/constraint, we would certainly overlflow > the >>>> RFC editor queue ;-) It would be nice to have a discussion on how > we >>>> could come up with the limited number of OF, taking out the >>>> metric/constraint from the OF semantics. That would greatly > simplify >>>> the work and still gives us the required flexibility. >>> >>> I reiterate that I'm not convinced this is a good idea. In this >>> domain, flexibility has a cost, in terms of code size and therefore >>> unit price. >>> >>> Phil >> >> _______________________________________________ >> 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_0090_01CAFDA8.C4594C00 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDUyNzEyMjc0MlowIwYJKoZI hvcNAQkEMRYEFGQ6aSC4lLHTrxOaf9SkzmUrqoObMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAxaTg IiP4WuSex5ueCED7LxoaQYKqRRuNuxF5ff2aohK3A/D+xtsLhegATvGXaDVWJ6Uo1R1p6R1YPP0P tlSiZ1cw8t7xJi7HXyduQLGWO/woeEcT+J4YsinYpd9Ch+ge+BqwqUpLrIliyzEaHw984pNlnCUx E6DQSoxAV7q09AMAAAAAAAA= ------=_NextPart_000_0090_01CAFDA8.C4594C00-- From jpv@cisco.com Thu May 27 06:02:01 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049DA3A6AAB for ; Thu, 27 May 2010 06:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.129 X-Spam-Level: X-Spam-Status: No, score=-9.129 tagged_above=-999 required=5 tests=[AWL=1.469, 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 hm6O3XstdUkh for ; Thu, 27 May 2010 06:01:59 -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 A0CE83A6A9B for ; Thu, 27 May 2010 06:01:57 -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: AvcBAOoJ/kuQ/uCWe2dsb2JhbACBP5xcFQEBFiIGHKZnmhyFEwQ X-IronPort-AV: E=Sophos;i="4.53,311,1272844800"; d="scan'208,217";a="61902156" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 May 2010 13:01:47 +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 o4RD1lxo028513 for ; Thu, 27 May 2010 13:01:47 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 May 2010 15:01:47 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 May 2010 15:01:46 +0200 Message-Id: <0F3E2705-2A94-4E19-98A7-3A728FC0ACDB@cisco.com> From: JP Vasseur To: "Mathilde Durvy (mdurvy)" In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0225E393@XMB-AMS-103.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-448-305361728 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 May 2010 15:01:44 +0200 References: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu><2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D01F96BE1@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0225E393@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 May 2010 13:01:46.0429 (UTC) FILETIME=[C3268ED0:01CAFD9C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17408.007 X-TM-AS-Result: No--30.704500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraintsfromObjective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 13:02:01 -0000 --Apple-Mail-448-305361728 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On May 27, 2010, at 2:27 PM, Mathilde Durvy (mdurvy) wrote: > Hi JP, Pascal, > > I like the idea of decoupling things, however I'm not quite sure to > understand how it would work. Does it mean that there is no OCP object > carried by the DIO, only metric/constraint objects which include how > to use > them? There would be an OF specified along the lines on Section 10: 10. Guidelines for Objective Functions . . . . . . . . . . . . . . 59 And by the way, as you can see we do not specify the metrics in use. And the metrics/constraints would be specified independently using the DAG metric Container. A node could (if needed) add policy functions. Does that make sense ? Thanks. JP. > If this is the case how do you assess that you support the OCP? How > do you > know which objective function to call when you receive a DIO? In > short how > does this decoupling affect the DIO processing. > (right now, in our implementation when a node receives a DIO, it > simply > looks at the ocp and based on this value it calls the corresponding > objective function (an actual C function) to order the potential > parent with > respect to the existing ones) > > Best, > Mathilde > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP > Vasseur > Sent: jeudi, 27. mai 2010 11:38 > To: Pascal Thubert (pthubert) > Cc: roll@ietf.org WG > Subject: Re: [Roll] [roll] #38: Decoupling routing > metrics/constraintsfromObjective function > > > On May 27, 2010, at 11:28 AM, Pascal Thubert (pthubert) wrote: > >> Hi Yoav and Dominique: >> >> I agree with you all that we need to decouple. In my mind image, the >> OF ties the result of the metric computation with some other policies >> that implement the objective. > > yes > >> If we need some logic to play with the metrics themselves in order to >> figure out something scalar off them, that should come with the >> metrics, like having a metrics function in parallel to the objective >> function. >> So, would you need a code for that metric function? Would that be in >> the metric draft then? > > if for example, you need to come with a polynomial function of > multiple > metrics (this was a suggestion from Dominique some time ago), this > would > indeed be an object in the metric-ID. For the time being, we already > have > the flexibility to add metrics/constraints (and indicate their > nature) in > the ID > > jP. > >> >> Pascal >> >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> Of >>> Yoav Ben-Yehezkel >>> Sent: Thursday, May 27, 2010 11:05 AM >>> To: JP Vasseur; Philip Levis >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/ >>> constraints fromObjective function >>> >>> Hi, >>> >>> I agree that whatever we select in the end must not require us to >> define a >>> new OF per "metric/constraint combination". >>> >>> I agree that if we come up with a small limited set of OFs - that >> might be >>> simpler to code, but not very flexible or extendible. My current >> impression is >>> that the decoupling that the metric supports now is highly flexible >>> in >> this >>> perspective and not that complex. >>> >>> We've had cases where we started off with one metric installed a few >>> thousands of units, only to realize that we didn't think about a few >>> constraints as well. It would have made backwards compatibility >>> issues >> much >>> easier to handle if our stack was ready to have the constraints >> further down >>> the road. >>> >>> Best regards, >>> Yoav >>> >>> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> Of JP >>> Vasseur >>> Sent: Wednesday, May 26, 2010 7:22 PM >>> To: Philip Levis >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/ >>> constraints >> from >>> Objective function >>> >>> Hi Phil, >>> >>> Point well taken. Let me try to quickly reiterate the argument and >>> get >> feed- >>> back from others (this is why I opened a ticket to hear the opinion >>> of >> others). >>> >>> In the metric-ID, we have defined a set of routing attributes that >>> can >> be used >>> as constraints and/or metrics, which will be carried in the DAG >> container >>> object. We currently have the concept of OF that determines a set of >> rule for >>> DODAG parent selection, ... >>> >>> There are two options: >>> 1) We decide to hard-code the metric/constraint (remember that >>> constrained-based routing is a MUST in the requirement documents) in >> the >>> OF >>> 2) We keep the decoupling option as defined today in the metric ID. >>> >>> 1) simply means that each time you define a new combination of >>> metric >>> and/or constraint, you must redefine a new OF ! As I was pointed out >> when >>> we had a discussion, looking at the spectrum of applications we will >> likely >>> have to define a *number* of OF, with little flexibility in the >> deployments. >>> Just for the sake of illustration, take one application Smart Grid: >>> if >> you look at >>> RPL deployment for Smart Metering, Distribution Automation, Home >> Energy >>> management, you already have at least 3 or 4 OFs since these >> applications >>> will not use the same metrics and/or constraints (ETX, Delays, >> battery- >>> operated constraint, ...). Now considering all of the other >> applications >>> (Industrial, building, home), one can easily see that this won't >> scale. >>> >>> So the proposal is easy ... just remove the hard coding constraint >> from the OF >>> definition, and this provides you a much more flexible solution at >>> no >> cost. >>> Then you will drastically reduce the number of OF to specify. >>> >>> >>> I do not agree with your "Cost" argument. This is in fact most >>> likely >> the >>> opposite since some devices will have to support multiple instances, >> thus >>> most likely, multiple OF if you hard code the metric/constraint, >>> thus >> leading >>> to more cost complexity. >>> >>> Last but not least, you can also have scenarios where you may want >>> to >> relax >>> constraint. With 1), no need to support multiple OFs, you just >>> remove >> the >>> constraint. >>> >>> Thoughts from others ? >>> >>> JP. >>> >>> >>> On May 26, 2010, at 6:00 PM, Philip Levis wrote: >>> >>>> >>>> On May 26, 2010, at 2:52 AM, roll issue tracker wrote: >>>> >>>>> #38: Decoupling routing metrics/constraints from Objective >>>>> function >>>>> -------------------------------- >>>>> +------------------------------------------- >>>>> Reporter: jpv@. | Owner: jpv@. >>>>> Type: defect | Status: new >>>>> Priority: major | Milestone: >>>>> Component: rpl | Version: >>>>> Severity: Active WG Document | Keywords: >>>>> -------------------------------- >>>>> +------------------------------------------- >>>>> Email for JP Vasseur April 14: >>>>> >>>>> Dear all, >>>>> >>>>> Just an (important) clarification: as you know, we have defined >>>>> routing "attributes" in the metric ID to be used as metrics or a >>>>> constraints. And considering the number of applications for RPL, >>>>> we >>>>> will more than likely see a number of combinations of metrics >> and/or >>>>> constraints. Should we want to specify an OF each time we want to >> use >>>>> of combination of metric/constraint, we would certainly overlflow >> the >>>>> RFC editor queue ;-) It would be nice to have a discussion on how >> we >>>>> could come up with the limited number of OF, taking out the >>>>> metric/constraint from the OF semantics. That would greatly >> simplify >>>>> the work and still gives us the required flexibility. >>>> >>>> I reiterate that I'm not convinced this is a good idea. In this >>>> domain, flexibility has a cost, in terms of code size and therefore >>>> unit price. >>>> >>>> Phil >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-448-305361728 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

On May = 27, 2010, at 2:27 PM, Mathilde Durvy (mdurvy) wrote:

Hi = JP, Pascal,

I like the idea of decoupling things, however I'm not = quite sure to
understand how it would work. Does it mean that there = is no OCP object
carried by the DIO, only metric/constraint objects = which include how to = use
them?

There would be an = OF specified along the lines on Section 10: 
= 10. Guidelines for Objective Functions . . . . . . . . . . . . . = . 59

And by the way, as you can see we = do not specify the metrics in use.
And the metrics/constraints = would be specified independently using the DAG metric = Container.
A node could (if needed) add policy = functions.

Does that make sense = ?

Thanks.

JP.

<= blockquote type=3D"cite">
If this is the case how do you assess that = you support the OCP? How do you
know which objective function to call = when you receive a DIO? In short how
does this decoupling affect the = DIO processing.
(right now, in our implementation when a node = receives a DIO, it simply
looks at the ocp and based on this value it = calls the corresponding
objective function (an actual C function) to = order the potential parent with
respect to the existing ones) =

Best,
Mathilde

-----Original Message-----
From: = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of JP
Vasseur
Sent: jeudi, 27. mai 2010 11:38
To: = Pascal Thubert (pthubert)
Cc: roll@ietf.org WG
Subject: Re: = [Roll] [roll] #38: Decoupling = routing
metrics/constraintsfromObjective function


On May = 27, 2010, at 11:28 AM, Pascal Thubert (pthubert) = wrote:

Hi Yoav and = Dominique:

I agree with = you all that we need to decouple. In my mind image, the =
OF ties the result of the = metric computation with some other policies
that implement the = objective.

yes

If = we need some logic to play with the metrics themselves in order to =
figure out something scalar = off them, that should come with the
metrics, like having a metrics function in parallel to the = objective
function.
So, = would you need a code for that metric function? Would that be in =
the metric draft = then?

if for example, you need to come with a = polynomial function of multiple
metrics (this was a suggestion from = Dominique some time ago), this would
indeed be an object in the = metric-ID. For the time being, we already have
the flexibility to add = metrics/constraints (and indicate their nature) in
the = ID

jP.


Pascal


-----Original = Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf
Of
Yoav Ben-Yehezkel
Sent: Thursday, May 27, 2010 = 11:05 AM
To: JP Vasseur; Philip = Levis
Cc: roll@ietf.org
Subject: Re: = [Roll] [roll] #38: Decoupling routing metrics/ =
constraints fromObjective = function

Hi,

I agree that whatever we select = in the end must not require us = to
define = a
new = OF per "metric/constraint = combination".

I agree that if we come up with = a small limited set of OFs - = that
might = be
simpler to code, but not very flexible or extendible. My = current
impression = is
that the decoupling that the metric supports now is highly = flexible
in
this
perspective and not that = complex.

We've had cases where we started = off with one metric installed a few =
thousands of units, only to realize that we didn't think = about a few
constraints as well. It would = have made backwards compatibility =
issues
much
easier to handle if our stack was ready to have the = constraints
further= down
the road.

Best = regards,
Yoav


-----Original = Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf
Of = JP
Vasseur
Sent: Wednesday, May 26, 2010 = 7:22 PM
To: Philip Levis
Cc: roll@ietf.org
Subject: Re: = [Roll] [roll] #38: Decoupling routing metrics/ =
constraints
from
Objective = function

Hi = Phil,

Point well taken. Let me try to = quickly reiterate the argument and =
get
feed-
back from others (this is why I opened a ticket to hear = the opinion
of
others).

In the metric-ID, we have = defined a set of routing attributes that =
can
be used
as constraints and/or metrics, = which will be carried in the = DAG
container
object. We currently have the = concept of OF that determines a set = of
rule = for
DODAG parent selection, = ...

There are two = options:
1) We decide to hard-code the = metric/constraint (remember that =
constrained-based routing is a MUST in the requirement = documents) in
the
OF
2) We keep the decoupling option = as defined today in the metric = ID.

1) simply means that each time = you define a new combination of metric =
and/or constraint, you must redefine a new OF ! As I was = pointed out
when
we had a discussion, looking at the spectrum of = applications we will
likely
have to define a *number* of OF, with little flexibility = in the
deployments.
Just for the sake of = illustration, take one application Smart Grid: =  
if
you look at
RPL deployment for Smart = Metering, Distribution Automation, = Home
Energy
management, you already have at least 3 or 4 OFs since = these
applications
will not use the same metrics = and/or constraints (ETX, = Delays,
battery-
operated constraint, ...). Now = considering all of the other
applications
(Industrial, building, home), = one can easily see that this = won't
scale.

So the proposal is easy ... just = remove the hard coding = constraint
from = the OF
definition, and this provides you a much more flexible = solution at no
cost.
Then you will drastically reduce the number of OF to = specify.


I do not agree with your "Cost" = argument. This is in fact most = likely
the
opposite since some devices will have to support multiple = instances,
thus
most likely, multiple OF if you hard code the = metric/constraint, thus
leading
to more cost = complexity.

Last but not least, you can also = have scenarios where you may want = to
relax
constraint. With 1), no need to support multiple OFs, you = just remove
the
constraint.

Thoughts from others = ?

JP.


On May 26, 2010, at 6:00 PM, = Philip Levis wrote:


On May = 26, 2010, at 2:52 AM, roll issue tracker = wrote:

#38: Decoupling routing = metrics/constraints from Objective = function
--------------------------------
+-------------------------------------------
Reporter:  jpv@. =             &n= bsp; |       Owner: =  jpv@.
  Type:  defect =             &n= bsp;|      Status: =  new
Priority:  major =             &n= bsp; | =   Milestone:
Component:  rpl =             &n= bsp;   | =     Version:
Severity:  Active WG Document  | =    Keywords:
--------------------------------
+-------------------------------------------
Email for JP Vasseur April = 14:

Dear = all,

Just an (important) = clarification: as you know, we have defined =
routing "attributes" in the = metric ID to be used as metrics or a =
constraints. And considering the = number of applications for RPL, we =
will more than likely see a = number of combinations of = metrics
and/or
constraints. Should we want to = specify an OF each time we want = to
use
of = combination of metric/constraint, we would certainly = overlflow
the
RFC = editor queue ;-) It would be nice to have a discussion on = how
we
could = come up with the limited number of OF, taking out the =
metric/constraint from the OF = semantics. That would = greatly
simplify
the work and still gives us the = required = flexibility.

I = reiterate that I'm not convinced this is a good idea. In this =
domain, = flexibility has a cost, in terms of code size and therefore =
unit = price.

Phil

_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_____________________________= __________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-448-305361728-- From richard.kelsey@ember.com Thu May 27 08:04:08 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6DC13A694A for ; Thu, 27 May 2010 08:04:08 -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 WhhcduWKkP1z for ; Thu, 27 May 2010 08:04:07 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id B5F513A6917 for ; Thu, 27 May 2010 08:04:07 -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, 27 May 2010 11:03:58 -0400 Date: Thu, 27 May 2010 11:01:40 -0400 Message-Id: <87typtxuaz.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: <2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com> (message from JP Vasseur on Wed, 26 May 2010 18:22:27 +0200) From: Richard Kelsey References: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu> <2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com> X-OriginalArrivalTime: 27 May 2010 15:03:58.0048 (UTC) FILETIME=[D522D600:01CAFDAD] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraints from Objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 15:04:09 -0000 > From: JP Vasseur > Date: Wed, 26 May 2010 18:22:27 +0200 > > There are two options: > 1) We decide to hard-code the metric/constraint (remember that > constrained-based routing is a MUST in the > requirement documents) in the OF > 2) We keep the decoupling option as defined today in the metric ID. Here is a third option :-). I think there are really three categories of information, not two: - Path-specific metric/constraint values, such as the actual ETX or latency of a path. - Evaluation and combining functions for comparing sets of metric/constraint values and calculating rank deltas. Is an ETX=2, Latency=5 path better or worse than ETX=3, Latency=4 path, and by how much? - The OF, which uses an evaluation function in determining which parents to use, and so forth. Only the path-specific metric/constraint values need to be in every DIO. Some of the information currently sent in the Metric Container is really part of the evaluation function, in that it relates to how the values are used and not what they are. The evaluation function and the OF should go in the DODAG Configuration suboption. If you change the evaluation function or the OF, then you are making a different DODAG. Both the evaluation function and the OF are likely to have static parameters that could be included in the DODAG Configuration suboption or be configured out-of-band. The evaluation function might have dynamic parameters in addition to the metric values themselves, to allow for things like tuning the relative importance of latency and reliability, say. I guess these could go in the Metric Container. This could all all be broken down into something like the following: - The RPL draft. - The metric draft. - A draft defining a set of evaluation functions, similar to the cryptographic suites used by TLS and IPsec. Examples are minimize RTX, maximize latency, and so forth. - A parameterized generic OF -Richard Kelsey From nicolas.dejean.ietf@googlemail.com Thu May 27 09:01:42 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120933A696F for ; Thu, 27 May 2010 09:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 i+D5+YMBgbNk for ; Thu, 27 May 2010 09:01:41 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id E3D213A6982 for ; Thu, 27 May 2010 09:01:40 -0700 (PDT) Received: by ewy8 with SMTP id 8so37736ewy.28 for ; Thu, 27 May 2010 09:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=pTDdPz4Lfr+9GBlRgYauOsiaSfCYnl3OoqZWBhHSGx4=; b=NF/aweZLehXrLbzTsiTeHCgkb0hd4/pMfhEvmGnkr6g5DnZV+eA9TJIJyjrBKoK9fr Z4w3YlLWtG47nMJl6qLCXrpPJD3wI7wxUUDfULxtHY67GbFZHCozS45eIg5Qn5Yqddf5 SVLTCulAO3xXcazAEqzZHFPTQO1sooK5+occA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iu3Z9XTRzk5iqUpVhSkMQm+pVvhDuVR2mdODkBdNduXVIcSpP/h7Uq6hVZ+y/DBDqt prqRa9q4vZpoWUP0I0ls3QTSuCk2uO2dbJyKCzeVZz5qhXDedrnlVbQ/74OatpZJjWP1 uJKus4zTkfwCIpdo0ZR5IotQU9OR8S5bHjGk0= MIME-Version: 1.0 Received: by 10.213.22.193 with SMTP id o1mr1859446ebb.69.1274976088186; Thu, 27 May 2010 09:01:28 -0700 (PDT) Received: by 10.213.20.6 with HTTP; Thu, 27 May 2010 09:01:28 -0700 (PDT) In-Reply-To: <87typtxuaz.fsf@kelsey-ws.hq.ember.com> References: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu> <2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com> <87typtxuaz.fsf@kelsey-ws.hq.ember.com> Date: Thu, 27 May 2010 18:01:28 +0200 Message-ID: From: Nicolas DEJEAN To: Richard Kelsey Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraints from Objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 16:01:42 -0000 Hello WG, I tend to favor an approach where constraints and cost functions can be altered at run-time. a. during the installation phase, it is important to be able to release some constraints if the connectivity is considered insufficient after network initial build-up b. as the network approaches the end of its life, it is highly desirable to be able to fine tune its behavior based on its observed status, to make the best use of its last gulps of energy. c. because we intend to have our networks operate for 10 or 20 years, but we are pressured for deploying them soon, we trust that researchers will come with improved ways to combine metrics and constraints over the network lifetime (compound metrics, weight factors, etc). Not being able to retrofit (without reflashing) research results into an existing network for 20 years seems like a tremendous waste of brainpower. Another point is that in the current situation and with my understanding, the OF has to define at least the following "things": - the parent selection and usage policy (choose one or several parents, usage of load balancing, ...) - the metrics and constraints in use and how to combine them, - the rank computation function. - ... That means that each time we want to change one of these parameters, we have to define a new OF. Decoupling metrics and constraints from the other parts of the OF would already drastically reduce the risk of seeing an unmanageable number of different OFs on the market. As a conclusion, I woul say that decoupling OF and metrics would not only give us a powerful tool for dynamic network optimization but also allow us making a big step in the right direction for insuring the interoperability of equipments coming from different vendors. Your thoughts? Nicolas. From jhui@archrock.com Thu May 27 09:20:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3892C3A698D for ; Thu, 27 May 2010 09:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[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 h1jJMylIi5sT for ; Thu, 27 May 2010 09:20:47 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id D3BAA3A6B3B for ; Thu, 27 May 2010 09:20:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 801B3AF92F for ; Thu, 27 May 2010 09:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYw8R04UE5bd for ; Thu, 27 May 2010 09:20:33 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id E235BAFA42 for ; Thu, 27 May 2010 09:20:32 -0700 (PDT) Message-Id: <6477E121-6289-4868-A443-E0113B5267A2@archrock.com> From: Jonathan Hui To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 May 2010 09:20:31 -0700 References: <20100526184121.2F0763A68D6@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 16:20:52 -0000 To address RPL ticket #35, we submitted a draft to 6man that proposes a new IPv6 routing header to support source routing in non-storing mode. Some high-level details: - Format is derived from RH0 - Format is extended to support simple compression of IPv6 address entries within the routing header - Use of the RPL routing header is constrained to a RPL domain. http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-00 Comments appreciated as always. -- Jonathan Hui Begin forwarded message: > From: IETF I-D Submission Tool > Date: May 26, 2010 11:41:21 AM PDT > To: jhui@archrock.com > Cc: jpv@cisco.com,culler@cs.berkeley.edu > Subject: New Version Notification for draft-hui-6man-rpl-routing- > header-00 > > > A new version of I-D, draft-hui-6man-rpl-routing-header-00.txt has > been successfully submitted by Jonathan Hui and posted to the IETF > repository. > > Filename: draft-hui-6man-rpl-routing-header > Revision: 00 > Title: A Source Routing Header for RPL > Creation_date: 2010-05-26 > WG ID: Independent Submission > Number_of_pages: 13 > > Abstract: > In Low power and Lossy Networks (LLNs), memory constraints on routers > may limit them to maintaining at most a few routes. In some > configurations, it is necessary to use these memory constrained > routers to deliver datagrams to nodes within the LLN. The Routing > for Low Power and Lossy Networks (RPL) protocol can be used in some > deployments to store most, if not all, routes on one (e.g. the > Directed Acyclic Graph (DAG) root) or few routers and forward the > IPv6 datagram using a source routing technique to avoid large routing > tables on memory constrained routers. This document specifies a new > IPv6 Routing header type for delivering datagrams within a RPL > domain. > > > > The IETF Secretariat. > > From yoav@yitran.com Thu May 27 09:47:36 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82AA3A6B4A for ; Thu, 27 May 2010 09:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.677 X-Spam-Level: X-Spam-Status: No, score=-4.677 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 aOP1KYRDg8-2 for ; Thu, 27 May 2010 09:47:36 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by core3.amsl.com (Postfix) with SMTP id 8FBE73A6819 for ; Thu, 27 May 2010 09:47:35 -0700 (PDT) Received: from source ([74.125.82.50]) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKS/6iHX7xQZyYcMdQrq4JeFsUEpfJ7vr3@postini.com; Thu, 27 May 2010 09:47:26 PDT Received: by mail-ww0-f50.google.com with SMTP id 33so208826wwc.23 for ; Thu, 27 May 2010 09:47:25 -0700 (PDT) Received: by 10.216.186.5 with SMTP id v5mr6826wem.51.1274978845440; Thu, 27 May 2010 09:47:25 -0700 (PDT) From: Yoav Ben-Yehezkel References: <20100526184121.2F0763A68D6@core3.amsl.com> <6477E121-6289-4868-A443-E0113B5267A2@archrock.com> In-Reply-To: <6477E121-6289-4868-A443-E0113B5267A2@archrock.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr9uJKriDCSAroNRrmOmjQ0S+A1QgAAzyWQ Date: Thu, 27 May 2010 19:47:23 +0300 Message-ID: <0dca2e3d073a4719d97ff5a80d144ece@mail.gmail.com> To: Jonathan Hui , ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 16:47:37 -0000 Hi, Two small questions/comments about the following text (on page 6) else if Address[i] is not an neighboring node { send an ICMP Destination Unreachable, Code 3, message to the Source Address and discard the packet 1) How does a non-storing device knows Address[i] is not an neighboring node? It is non storing... 2) Code 3 - should be Code 7? also consider changing header from: "RPL Routing Header" to: "Source Routing Header for RPL" Best Regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui Sent: Thursday, May 27, 2010 7:21 PM To: ROLL WG Subject: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 To address RPL ticket #35, we submitted a draft to 6man that proposes a new IPv6 routing header to support source routing in non-storing mode. Some high-level details: - Format is derived from RH0 - Format is extended to support simple compression of IPv6 address entries within the routing header - Use of the RPL routing header is constrained to a RPL domain. http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-00 Comments appreciated as always. -- Jonathan Hui Begin forwarded message: > From: IETF I-D Submission Tool > Date: May 26, 2010 11:41:21 AM PDT > To: jhui@archrock.com > Cc: jpv@cisco.com,culler@cs.berkeley.edu > Subject: New Version Notification for draft-hui-6man-rpl-routing- > header-00 > > > A new version of I-D, draft-hui-6man-rpl-routing-header-00.txt has > been successfully submitted by Jonathan Hui and posted to the IETF > repository. > > Filename: draft-hui-6man-rpl-routing-header > Revision: 00 > Title: A Source Routing Header for RPL > Creation_date: 2010-05-26 > WG ID: Independent Submission > Number_of_pages: 13 > > Abstract: > In Low power and Lossy Networks (LLNs), memory constraints on routers > may limit them to maintaining at most a few routes. In some > configurations, it is necessary to use these memory constrained > routers to deliver datagrams to nodes within the LLN. The Routing > for Low Power and Lossy Networks (RPL) protocol can be used in some > deployments to store most, if not all, routes on one (e.g. the > Directed Acyclic Graph (DAG) root) or few routers and forward the > IPv6 datagram using a source routing technique to avoid large routing > tables on memory constrained routers. This document specifies a new > IPv6 Routing header type for delivering datagrams within a RPL > domain. > > > > The IETF Secretariat. > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Thu May 27 09:56:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5C03A6B41 for ; Thu, 27 May 2010 09:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 u7cRRyzpBHcS for ; Thu, 27 May 2010 09:56:50 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 0C6583A67F2 for ; Thu, 27 May 2010 09:56:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id E97B6AFA0C; Thu, 27 May 2010 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf1InM+bKSO6; Thu, 27 May 2010 09:56:36 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id C785FAF8EB; Thu, 27 May 2010 09:56:36 -0700 (PDT) Message-Id: <88A83D23-A069-4CBB-AF43-182F1FBF51DD@archrock.com> From: Jonathan Hui To: Yoav Ben-Yehezkel In-Reply-To: <0dca2e3d073a4719d97ff5a80d144ece@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 May 2010 09:56:35 -0700 References: <20100526184121.2F0763A68D6@core3.amsl.com> <6477E121-6289-4868-A443-E0113B5267A2@archrock.com> <0dca2e3d073a4719d97ff5a80d144ece@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 16:56:51 -0000 On May 27, 2010, at 9:47 AM, Yoav Ben-Yehezkel wrote: > Two small questions/comments about the following text (on page 6) > > else if Address[i] is not an neighboring node { > send an ICMP Destination Unreachable, Code 3, message to > the Source Address and discard the packet > > 1) How does a non-storing device knows Address[i] is not an > neighboring > node? It is non storing... Non-storing means that it doesn't store routes for the destination. A node presumably needs to maintain some notion of neighbors, whether that's through ND or something similar. At the very least, a node could try forwarding the datagram and if it fails then it could indicate that it is not a neighbor. > 2) Code 3 - should be Code 7? Yes, you are right. We originally had Code 3, but through creating a new code would be more appropriate. > also consider changing header from: "RPL Routing Header" to: "Source > Routing Header for RPL" To be completely descriptive, maybe something like "An IPv6 Routing Header for Source Routing with RPL". We are describing a new IPv6 Routing type after all. -- Jonathan Hui > > Best Regards, > Yoav > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Jonathan Hui > Sent: Thursday, May 27, 2010 7:21 PM > To: ROLL WG > Subject: [Roll] Fwd: New Version Notification for > draft-hui-6man-rpl-routing-header-00 > > > To address RPL ticket #35, we submitted a draft to 6man that proposes > a new IPv6 routing header to support source routing in non-storing > mode. > > Some high-level details: > - Format is derived from RH0 > - Format is extended to support simple compression of IPv6 address > entries within the routing header > - Use of the RPL routing header is constrained to a RPL domain. > > http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-00 > > Comments appreciated as always. > > -- > Jonathan Hui > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: May 26, 2010 11:41:21 AM PDT >> To: jhui@archrock.com >> Cc: jpv@cisco.com,culler@cs.berkeley.edu >> Subject: New Version Notification for draft-hui-6man-rpl-routing- >> header-00 >> >> >> A new version of I-D, draft-hui-6man-rpl-routing-header-00.txt has >> been successfully submitted by Jonathan Hui and posted to the IETF >> repository. >> >> Filename: draft-hui-6man-rpl-routing-header >> Revision: 00 >> Title: A Source Routing Header for RPL >> Creation_date: 2010-05-26 >> WG ID: Independent Submission >> Number_of_pages: 13 >> >> Abstract: >> In Low power and Lossy Networks (LLNs), memory constraints on routers >> may limit them to maintaining at most a few routes. In some >> configurations, it is necessary to use these memory constrained >> routers to deliver datagrams to nodes within the LLN. The Routing >> for Low Power and Lossy Networks (RPL) protocol can be used in some >> deployments to store most, if not all, routes on one (e.g. the >> Directed Acyclic Graph (DAG) root) or few routers and forward the >> IPv6 datagram using a source routing technique to avoid large routing >> tables on memory constrained routers. This document specifies a new >> IPv6 Routing header type for delivering datagrams within a RPL >> domain. >> >> >> >> The IETF Secretariat. >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Thu May 27 10:11:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307993A6B55 for ; Thu, 27 May 2010 10:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.327 X-Spam-Level: X-Spam-Status: No, score=-5.327 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 3Em1QuDZf2hf for ; Thu, 27 May 2010 10:11:23 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id 6F3FE3A68D7 for ; Thu, 27 May 2010 10:11:22 -0700 (PDT) Received: from source ([74.125.82.170]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKS/6nsJnr08gIBAQAOmlfGzYum+pOP8vE@postini.com; Thu, 27 May 2010 10:11:13 PDT Received: by mail-wy0-f170.google.com with SMTP id 36so151166wyg.29 for ; Thu, 27 May 2010 10:11:12 -0700 (PDT) Received: by 10.227.145.197 with SMTP id e5mr215271wbv.190.1274980271721; Thu, 27 May 2010 10:11:11 -0700 (PDT) From: Yoav Ben-Yehezkel References: <20100526184121.2F0763A68D6@core3.amsl.com> <6477E121-6289-4868-A443-E0113B5267A2@archrock.com> <0dca2e3d073a4719d97ff5a80d144ece@mail.gmail.com> <88A83D23-A069-4CBB-AF43-182F1FBF51DD@archrock.com> In-Reply-To: <88A83D23-A069-4CBB-AF43-182F1FBF51DD@archrock.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr9vZaNS3Ax5dOXQ/OSVUE7+cP7AAAASRiA Date: Thu, 27 May 2010 20:11:08 +0300 Message-ID: <423daf0d2fa6d072bd4d771b81eb6fbe@mail.gmail.com> To: Jonathan Hui Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 17:11:25 -0000 Jonathan, "Non-storing means that it doesn't store routes for the destination." OK, so another question is if it is a non-storing node, does it have to have the route back to the source stored (I guess so, because of the RPL mechanism, right?)? Or does it use the symmetric route back as indicated on the packet? And if so, should the text indicate this? "At the very least, a node could try forwarding the datagram and if it fails then it could indicate that it is not a neighbor." I completely agree, but my question is whether the text should indicate this explicitly to avoid confusion (one may understand this check is only internal database oriented)? Thanks, Yoav -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] Sent: Thursday, May 27, 2010 7:57 PM To: Yoav Ben-Yehezkel Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 On May 27, 2010, at 9:47 AM, Yoav Ben-Yehezkel wrote: > Two small questions/comments about the following text (on page 6) > > else if Address[i] is not an neighboring node { > send an ICMP Destination Unreachable, Code 3, message to > the Source Address and discard the packet > > 1) How does a non-storing device knows Address[i] is not an > neighboring > node? It is non storing... Non-storing means that it doesn't store routes for the destination. A node presumably needs to maintain some notion of neighbors, whether that's through ND or something similar. At the very least, a node could try forwarding the datagram and if it fails then it could indicate that it is not a neighbor. > 2) Code 3 - should be Code 7? Yes, you are right. We originally had Code 3, but through creating a new code would be more appropriate. > also consider changing header from: "RPL Routing Header" to: "Source > Routing Header for RPL" To be completely descriptive, maybe something like "An IPv6 Routing Header for Source Routing with RPL". We are describing a new IPv6 Routing type after all. -- Jonathan Hui > > Best Regards, > Yoav > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Jonathan Hui > Sent: Thursday, May 27, 2010 7:21 PM > To: ROLL WG > Subject: [Roll] Fwd: New Version Notification for > draft-hui-6man-rpl-routing-header-00 > > > To address RPL ticket #35, we submitted a draft to 6man that proposes > a new IPv6 routing header to support source routing in non-storing > mode. > > Some high-level details: > - Format is derived from RH0 > - Format is extended to support simple compression of IPv6 address > entries within the routing header > - Use of the RPL routing header is constrained to a RPL domain. > > http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-00 > > Comments appreciated as always. > > -- > Jonathan Hui > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: May 26, 2010 11:41:21 AM PDT >> To: jhui@archrock.com >> Cc: jpv@cisco.com,culler@cs.berkeley.edu >> Subject: New Version Notification for draft-hui-6man-rpl-routing- >> header-00 >> >> >> A new version of I-D, draft-hui-6man-rpl-routing-header-00.txt has >> been successfully submitted by Jonathan Hui and posted to the IETF >> repository. >> >> Filename: draft-hui-6man-rpl-routing-header >> Revision: 00 >> Title: A Source Routing Header for RPL >> Creation_date: 2010-05-26 >> WG ID: Independent Submission >> Number_of_pages: 13 >> >> Abstract: >> In Low power and Lossy Networks (LLNs), memory constraints on routers >> may limit them to maintaining at most a few routes. In some >> configurations, it is necessary to use these memory constrained >> routers to deliver datagrams to nodes within the LLN. The Routing >> for Low Power and Lossy Networks (RPL) protocol can be used in some >> deployments to store most, if not all, routes on one (e.g. the >> Directed Acyclic Graph (DAG) root) or few routers and forward the >> IPv6 datagram using a source routing technique to avoid large routing >> tables on memory constrained routers. This document specifies a new >> IPv6 Routing header type for delivering datagrams within a RPL >> domain. >> >> >> >> The IETF Secretariat. >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Thu May 27 13:01:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052B43A6974 for ; Thu, 27 May 2010 13:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, J_BACKHAIR_11=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 hfu+e3JllRXY for ; Thu, 27 May 2010 13:01:30 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 06C4E3A6924 for ; Thu, 27 May 2010 13:01:29 -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, 27 May 2010 16:01:20 -0400 Date: Thu, 27 May 2010 15:59:00 -0400 Message-Id: <87ocg1xgjf.fsf@kelsey-ws.hq.ember.com> To: roll@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 27 May 2010 20:01:20.0126 (UTC) FILETIME=[5FD7E1E0:01CAFDD7] Subject: [Roll] RPL ticket #32: Asymmetric Links - last call X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 20:01:31 -0000 Last chance to weigh in on ticket 32, before it is dropped due to lack of interest. Note 1: This ticket is not concerned with asymmetric links in general, but specifically with how path metrics are constructed from asymmetric link metrics. Note 2: The ticket is against the RPL draft, but this is really an issue for the routing metrics draft. The problem: An asymmetric link metric can be used to create a number of different path metrics, depending on how the upward and downward link metrics are incorporated into the path metric. The resulting path metric might reflect: - the metric for messages travelling upward - the metric for messages travelling downwards - average of the upward and downward metrics - best of the upward and downward metrics - worst of the upward and downward metrics and so on. Rather than try to encode all of the possible combining functions, we can allow the inclusion of both the upward and downward path metrics. A useful example here is latency in a network where nodes wake up to receive messages on a fixed schedule. If nodes A and B wake up to receive once a minute, with A waking up 5 seconds before B, then the A->B link has a latency of 5 seconds while B->A takes 55 seconds. If A chooses B as a parent when building a DODAG that uses latency as a metric, what value should it use for the latency of the A<->B link? Proposal: Add a flag to Routing Metric/Constraint to indicate whether the path metric represents the upward (flag = 0) or downward (flag = 1) metric. The flag would only be meaningful for path metrics that are aggregations of potentially asymmetric link metrics, such as latency or link quality, A single DAG Metric Container would be allowed contain two Routing Metric/Constraints of the same type, one containing the upward path metric and the other having the downward. Yes? No? -Richard Kelsey From yoav@yitran.com Thu May 27 13:52:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552F13A6971 for ; Thu, 27 May 2010 13:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.744 X-Spam-Level: X-Spam-Status: No, score=-3.744 tagged_above=-999 required=5 tests=[AWL=-1.367, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_BACKHAIR_11=1, 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 eG+xAJWobAJF for ; Thu, 27 May 2010 13:52:48 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by core3.amsl.com (Postfix) with SMTP id F0D3D3A6974 for ; Thu, 27 May 2010 13:52:47 -0700 (PDT) Received: from source ([74.125.82.182]) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKS/7bllVdGkjaf5cGcSRmLF89ac53Q5xY@postini.com; Thu, 27 May 2010 13:52:39 PDT Received: by mail-wy0-f182.google.com with SMTP id 26so420543wyj.13 for ; Thu, 27 May 2010 13:52:37 -0700 (PDT) Received: by 10.216.185.10 with SMTP id t10mr37619wem.32.1274993557748; Thu, 27 May 2010 13:52:37 -0700 (PDT) From: Yoav Ben-Yehezkel References: <87ocg1xgjf.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87ocg1xgjf.fsf@kelsey-ws.hq.ember.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr912W6tD5xne7WR/yKYUGkoZjvhQAByC3w Date: Thu, 27 May 2010 23:52:35 +0300 Message-ID: <61315397a85c92774888f858718e2ae0@mail.gmail.com> To: Richard Kelsey , roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] RPL ticket #32: Asymmetric Links - last call X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 20:52:49 -0000 +1 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Richard Kelsey Sent: Thursday, May 27, 2010 10:59 PM To: roll@ietf.org Subject: [Roll] RPL ticket #32: Asymmetric Links - last call Last chance to weigh in on ticket 32, before it is dropped due to lack of interest. Note 1: This ticket is not concerned with asymmetric links in general, but specifically with how path metrics are constructed from asymmetric link metrics. Note 2: The ticket is against the RPL draft, but this is really an issue for the routing metrics draft. The problem: An asymmetric link metric can be used to create a number of different path metrics, depending on how the upward and downward link metrics are incorporated into the path metric. The resulting path metric might reflect: - the metric for messages travelling upward - the metric for messages travelling downwards - average of the upward and downward metrics - best of the upward and downward metrics - worst of the upward and downward metrics and so on. Rather than try to encode all of the possible combining functions, we can allow the inclusion of both the upward and downward path metrics. A useful example here is latency in a network where nodes wake up to receive messages on a fixed schedule. If nodes A and B wake up to receive once a minute, with A waking up 5 seconds before B, then the A->B link has a latency of 5 seconds while B->A takes 55 seconds. If A chooses B as a parent when building a DODAG that uses latency as a metric, what value should it use for the latency of the A<->B link? Proposal: Add a flag to Routing Metric/Constraint to indicate whether the path metric represents the upward (flag = 0) or downward (flag = 1) metric. The flag would only be meaningful for path metrics that are aggregations of potentially asymmetric link metrics, such as latency or link quality, A single DAG Metric Container would be allowed contain two Routing Metric/Constraints of the same type, one containing the upward path metric and the other having the downward. Yes? No? -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Fri May 28 00:04:32 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5613A6826 for ; Fri, 28 May 2010 00:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.575 X-Spam-Level: X-Spam-Status: No, score=-7.575 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_50=0.001, J_BACKHAIR_11=1, 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 ymu55FCvvKed for ; Fri, 28 May 2010 00:04:31 -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 A8AD43A6811 for ; Fri, 28 May 2010 00:04:30 -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: AvsEAIkH/0tAZnwM/2dsb2JhbACeK3GkNJoYhRQE X-IronPort-AV: E=Sophos;i="4.53,317,1272844800"; d="scan'208";a="115668326" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 May 2010 07:04:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4S74B5I013675; Fri, 28 May 2010 07:04:20 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 May 2010 09:04:13 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 May 2010 09:04:12 +0200 Message-Id: <39184AF4-E6CD-4521-A8AC-01F7B8E8C683@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <87ocg1xgjf.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 28 May 2010 09:04:12 +0200 References: <87ocg1xgjf.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 May 2010 07:04:12.0951 (UTC) FILETIME=[FA4B5A70:01CAFE33] Cc: roll@ietf.org Subject: Re: [Roll] RPL ticket #32: Asymmetric Links - last call X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 07:04:32 -0000 On May 27, 2010, at 9:59 PM, Richard Kelsey wrote: > Last chance to weigh in on ticket 32, before it is dropped > due to lack of interest. > > Note 1: This ticket is not concerned with asymmetric links in > general, but specifically with how path metrics are constructed > from asymmetric link metrics. > > Note 2: The ticket is against the RPL draft, but this is really > an issue for the routing metrics draft. > > > The problem: > > An asymmetric link metric can be used to create a number of > different path metrics, depending on how the upward and > downward link metrics are incorporated into the path metric. > The resulting path metric might reflect: > - the metric for messages travelling upward > - the metric for messages travelling downwards > - average of the upward and downward metrics > - best of the upward and downward metrics > - worst of the upward and downward metrics > and so on. > > Rather than try to encode all of the possible combining > functions, we can allow the inclusion of both the upward > and downward path metrics. > > A useful example here is latency in a network where nodes > wake up to receive messages on a fixed schedule. If nodes A > and B wake up to receive once a minute, with A waking up 5 > seconds before B, then the A->B link has a latency of 5 > seconds while B->A takes 55 seconds. If A chooses B as a > parent when building a DODAG that uses latency as a metric, > what value should it use for the latency of the A<->B link? > > > Proposal: > > Add a flag to Routing Metric/Constraint to indicate whether > the path metric represents the upward (flag = 0) or downward > (flag = 1) metric. The flag would only be meaningful for > path metrics that are aggregations of potentially asymmetric > link metrics, such as latency or link quality, > > A single DAG Metric Container would be allowed contain two > Routing Metric/Constraints of the same type, one containing > the upward path metric and the other having the downward. > > > Yes? No? Works for me (as authors of metric ID). Thanks. JP. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mdurvy@cisco.com Fri May 28 01:25:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC55328C0F5 for ; Fri, 28 May 2010 01:22:50 -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=-0.185, BAYES_20=-0.74, 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 Z+hYzx3YT-Ny for ; Fri, 28 May 2010 01:22:28 -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 5688E3A69FD for ; Fri, 28 May 2010 01:16:49 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4235 X-IronPort-AV: E=Sophos;i="4.53,317,1272844800"; d="p7s'?scan'208,217";a="115687453" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 May 2010 08:16:33 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4S8GZPi001967; Fri, 28 May 2010 08:16:35 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, 28 May 2010 10:16:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 May 2010 10:16:31 +0200 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0195_01CAFE4E.D76512B0"; protocol="application/x-pkcs7-signature" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0225E6B5@XMB-AMS-103.cisco.com> In-Reply-To: <0F3E2705-2A94-4E19-98A7-3A728FC0ACDB@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #38: Decoupling routing metrics/constraintsfromObjective function Thread-Index: Acr9nMOaD3df5A9hSY6bi002egMe8AAoK6cA References: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu><2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D01F96BE1@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0225E393@XMB-AMS-103.cisco.com> <0F3E2705-2A94-4E19-98A7-3A728FC0ACDB@cisco.com> From: "Mathilde Durvy (mdurvy)" To: "JP Vasseur" X-OriginalArrivalTime: 28 May 2010 08:16:32.0388 (UTC) FILETIME=[14CCE440:01CAFE3E] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraintsfromObjective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 08:25:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0195_01CAFE4E.D76512B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0196_01CAFE4E.D76512B0" ------=_NextPart_001_0196_01CAFE4E.D76512B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi JP, [JP] There would be an OF specified along the lines on Section 10: 10. Guidelines for Objective Functions . . . . . . . . . . . . . . 59 And by the way, as you can see we do not specify the metrics in use. And the metrics/constraints would be specified independently using the DAG metric Container. A node could (if needed) add policy functions. Does that make sense ? Yes, so if I take the only example of OF given in Section 10 "minimize the path cost using the ETX metric and avoid 'Blue' links". Using the decoupling approach we would say something like "minimize the path cost as defined by the metric container and avoid links as specified by the constraint object". Correct? Best, Mathilde ------=_NextPart_001_0196_01CAFE4E.D76512B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi JP,

 [JP]  There would be an OF = specified=20 along the lines on Section 10: 
10. Guidelines for Objective Functions . . . . = . . . . . .=20 . . . . 59
And by the way, as you = can see we do=20 not specify the metrics in use.
And the = metrics/constraints would be=20 specified independently using the DAG metric Container.
A node could (if = needed) add policy=20 functions.
 
Yes, so if I take the only = example of OF=20 given in Section=20 10  "minimize the path cost using the ETX metric and = avoid=20 'Blue' links".  Using = the=20 decoupling approach we = would say=20 something like "minimize the path cost as defined by the metric = container and=20 avoid links as specified by the constraint object". Correct?
Best,
Mathilde 
------=_NextPart_001_0196_01CAFE4E.D76512B0-- ------=_NextPart_000_0195_01CAFE4E.D76512B0 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDUyODA4MTYzMFowIwYJKoZI hvcNAQkEMRYEFO7EMYF3LIWbm44Lm61RPHQOBsilMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAGYOO 7mKiEC1VKy3VFA83MinS8qaGM1ULw+8gFfwKYgCTeQUWWrodtvSb0JUBTMGJynCVaYvlUU7awwP/ 4LK8Qu3s/osPtw5R/8RknVbY6RNqj8njaN3WBIT5JJKmIARo3V2SCL/8O0MVNAs9KgOk5rCGpNFF UzffB03eLqtKZWwAAAAAAAA= ------=_NextPart_000_0195_01CAFE4E.D76512B0-- From jpv@cisco.com Fri May 28 02:45:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9B73A68A2 for ; Fri, 28 May 2010 02:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.292 X-Spam-Level: X-Spam-Status: No, score=-9.292 tagged_above=-999 required=5 tests=[AWL=1.306, 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 EE+wZnlMDExq for ; Fri, 28 May 2010 02:45:24 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 59D853A6869 for ; Fri, 28 May 2010 02:45:24 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0GAD4t/0urR7Hu/2dsb2JhbACBP5xmcaQamiuFFAQ X-IronPort-AV: E=Sophos;i="4.53,317,1272844800"; d="scan'208,217";a="224457378" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 28 May 2010 09:45:14 +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 o4S9j1Sw014537 for ; Fri, 28 May 2010 09:45:14 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 May 2010 11:45:12 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 May 2010 11:45:11 +0200 Message-Id: <25498050-85AB-42EC-A913-BC0902680F3F@cisco.com> From: JP Vasseur To: Mathilde Durvy (mdurvy) In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0225E6B5@XMB-AMS-103.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-500-379892324 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 28 May 2010 11:43:55 +0200 References: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu><2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D01F96BE1@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0225E393@XMB-AMS-103.cisco.com> <0F3E2705-2A94-4E19-98A7-3A728FC0ACDB@cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0225E6B5@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 May 2010 09:45:12.0091 (UTC) FILETIME=[779726B0:01CAFE4A] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraintsfromObjective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 09:45:25 -0000 --Apple-Mail-500-379892324 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Mathilde, On May 28, 2010, at 10:16 AM, Mathilde Durvy (mdurvy) wrote: > Hi JP, > > [JP] There would be an OF specified along the lines on Section 10: > 10. Guidelines for Objective Functions . . . . . . . . . . . . . . 59 > And by the way, as you can see we do not specify the metrics in use. > And the metrics/constraints would be specified independently using > the DAG metric Container. > A node could (if needed) add policy functions. > Does that make sense ? > > Yes, so if I take the only example of OF given in Section 10 > "minimize the path cost using the ETX metric and avoid 'Blue' > links". Using the decoupling approach we would say something like > "minimize the path cost as defined by the metric container and avoid > links as specified by the constraint object". Correct? Absolutely. Do you agree with that plan ? Thanks. JP. > Best, > Mathilde --Apple-Mail-500-379892324 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Mathilde,

On May 28, 2010, at 10:16 AM, Mathilde Durvy = (mdurvy) wrote:

Hi JP,

=
 [JP]  There would be an = OF specified along the lines on Section = 10: 
10. = Guidelines for Objective Functions . . . . . . . . . . . . . . = 59
And by the way, as you can see we do not = specify the metrics in use.
And the metrics/constraints would be = specified independently using the DAG metric Container.
=
A node could (if = needed) add policy functions.
Does that make sense ?
=
 
Yes, so if I take the only = example of OF given in Section = 10  "minimize the path cost using the ETX metric and = avoid 'Blue' links".  Using the decoupling = approach we = would say something like "minimize the path cost as defined = by the metric container and avoid links as specified by the constraint = object". = Correct?

Absolutely.

Do you agree with that plan = ?

Thanks.

JP.

<= blockquote type=3D"cite">
=
Best,
Mathilde 

=
= --Apple-Mail-500-379892324-- From jpv@cisco.com Fri May 28 02:45:26 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A273A677D for ; Fri, 28 May 2010 02:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.455 X-Spam-Level: X-Spam-Status: No, score=-9.455 tagged_above=-999 required=5 tests=[AWL=1.143, 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 YH-6ZzsEQ0qW for ; Fri, 28 May 2010 02:45:25 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2DC3D3A67AB for ; Fri, 28 May 2010 02:45:25 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0GAD4t/0urR7Hu/2dsb2JhbACBP5xmcaQamiuFFAQ X-IronPort-AV: E=Sophos;i="4.53,317,1272844800"; d="scan'208,217";a="224457381" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 28 May 2010 09:45:15 +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 o4S9j1T0014537 for ; Fri, 28 May 2010 09:45:15 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 May 2010 11:45:14 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 May 2010 11:45:13 +0200 Message-Id: <3A1AA311-3F13-4E84-8708-48FD2982432A@cisco.com> From: JP Vasseur To: Mathilde Durvy (mdurvy) In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0225E6B5@XMB-AMS-103.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-501-379970186 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 28 May 2010 11:45:13 +0200 References: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu><2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D01F96BE1@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0225E393@XMB-AMS-103.cisco.com> <0F3E2705-2A94-4E19-98A7-3A728FC0ACDB@cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0225E6B5@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 May 2010 09:45:14.0154 (UTC) FILETIME=[78D1F0A0:01CAFE4A] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraintsfromObjective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 09:45:26 -0000 --Apple-Mail-501-379970186 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Mathilde, On May 28, 2010, at 10:16 AM, Mathilde Durvy (mdurvy) wrote: > Hi JP, > > [JP] There would be an OF specified along the lines on Section 10: > 10. Guidelines for Objective Functions . . . . . . . . . . . . . . 59 > And by the way, as you can see we do not specify the metrics in use. > And the metrics/constraints would be specified independently using > the DAG metric Container. > A node could (if needed) add policy functions. > Does that make sense ? > > Yes, so if I take the only example of OF given in Section 10 > "minimize the path cost using the ETX metric and avoid 'Blue' > links". Using the decoupling approach we would say something like > "minimize the path cost as defined by the metric container and avoid > links as specified by the constraint object". Correct? Absolutely. Do you agree with that plan ? Thanks. JP. > Best, > Mathilde --Apple-Mail-501-379970186 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Mathilde,

On May 28, 2010, at 10:16 AM, Mathilde Durvy = (mdurvy) wrote:

Hi JP,

=
 [JP]  There would be an = OF specified along the lines on Section = 10: 
10. = Guidelines for Objective Functions . . . . . . . . . . . . . . = 59
And by the way, as you can see we do not = specify the metrics in use.
And the metrics/constraints would be = specified independently using the DAG metric Container.
=
A node could (if = needed) add policy functions.
Does that make sense ?
=
 
Yes, so if I take the only = example of OF given in Section = 10  "minimize the path cost using the ETX metric and = avoid 'Blue' links".  Using the decoupling = approach we = would say something like "minimize the path cost as defined = by the metric container and avoid links as specified by the constraint = object". = Correct?

Absolutely.

Do you agree with that plan = ?

Thanks.

JP.

<= blockquote type=3D"cite">
=
Best,
Mathilde 

=
= --Apple-Mail-501-379970186-- From alexandru.petrescu@gmail.com Fri May 28 02:59:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A064A3A67F0 for ; Fri, 28 May 2010 02:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.758 X-Spam-Level: X-Spam-Status: No, score=0.758 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_50=0.001, HELO_EQ_FR=0.35, J_BACKHAIR_11=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 YORr9kFI7mtu for ; Fri, 28 May 2010 02:59:32 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 8EA353A6995 for ; Fri, 28 May 2010 02:59:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o4S9xLj4002419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 May 2010 11:59:21 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o4S9xK3o020404; Fri, 28 May 2010 11:59:21 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o4S9xKhW005671; Fri, 28 May 2010 11:59:20 +0200 Message-ID: <4BFF93F8.7030802@gmail.com> Date: Fri, 28 May 2010 11:59:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: roll@ietf.org References: <87ocg1xgjf.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87ocg1xgjf.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] RPL ticket #32: Asymmetric Links - last call X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 09:59:33 -0000 As I said earlier, I support using metrics for asymmetric links as long as we also include energy metrics. I have sent earlier an email describing how. Until then I don't think I agree using asymmetric link metrics. So I am not sure how to consider this: + or minus 1. Alex Le 27/05/2010 21:59, Richard Kelsey a écrit : > Last chance to weigh in on ticket 32, before it is dropped > due to lack of interest. > > Note 1: This ticket is not concerned with asymmetric links in > general, but specifically with how path metrics are constructed > from asymmetric link metrics. > > Note 2: The ticket is against the RPL draft, but this is really > an issue for the routing metrics draft. > > > The problem: > > An asymmetric link metric can be used to create a number of > different path metrics, depending on how the upward and > downward link metrics are incorporated into the path metric. > The resulting path metric might reflect: > - the metric for messages travelling upward > - the metric for messages travelling downwards > - average of the upward and downward metrics > - best of the upward and downward metrics > - worst of the upward and downward metrics > and so on. > > Rather than try to encode all of the possible combining > functions, we can allow the inclusion of both the upward > and downward path metrics. > > A useful example here is latency in a network where nodes > wake up to receive messages on a fixed schedule. If nodes A > and B wake up to receive once a minute, with A waking up 5 > seconds before B, then the A->B link has a latency of 5 > seconds while B->A takes 55 seconds. If A chooses B as a > parent when building a DODAG that uses latency as a metric, > what value should it use for the latency of the A<->B link? > > > Proposal: > > Add a flag to Routing Metric/Constraint to indicate whether > the path metric represents the upward (flag = 0) or downward > (flag = 1) metric. The flag would only be meaningful for > path metrics that are aggregations of potentially asymmetric > link metrics, such as latency or link quality, > > A single DAG Metric Container would be allowed contain two > Routing Metric/Constraints of the same type, one containing > the upward path metric and the other having the downward. > > > Yes? No? > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From mdurvy@cisco.com Fri May 28 04:27:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A1C3A6A45 for ; Fri, 28 May 2010 04:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.761 X-Spam-Level: X-Spam-Status: No, score=-9.761 tagged_above=-999 required=5 tests=[AWL=0.837, 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 a9AHvBXWqtx9 for ; Fri, 28 May 2010 04:26:56 -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 C667B3A6A1A for ; Fri, 28 May 2010 04:25:12 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4235 X-IronPort-AV: E=Sophos;i="4.53,317,1272844800"; d="p7s'?scan'208,217";a="204208846" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 28 May 2010 11:23:04 +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 o4SBN17U006641; Fri, 28 May 2010 11:23:03 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); Fri, 28 May 2010 13:22:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 May 2010 13:22:54 +0200 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_01C9_01CAFE68.E11564D0"; protocol="application/x-pkcs7-signature" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0225E855@XMB-AMS-103.cisco.com> In-Reply-To: <25498050-85AB-42EC-A913-BC0902680F3F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #38: Decoupling routing metrics/constraintsfromObjective function Thread-Index: Acr+SnfCkeLDoJrJQK+kZszbj/qgoAADYt6g References: <055.fe5b2f77c9d7f742dca81b757228af36@tools.ietf.org> <35648367-16AE-433B-A5C0-21141CA21F92@cs.stanford.edu><2EC4271F-71C4-4991-BA2F-6708437F6ED1@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D01F96BE1@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0225E393@XMB-AMS-103.cisco.com> <0F3E2705-2A94-4E19-98A7-3A728FC0ACDB@cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0225E6B5@XMB-AMS-103.cisco.com> <25498050-85AB-42EC-A913-BC0902680F3F@cisco.com> From: "Mathilde Durvy (mdurvy)" To: "JP Vasseur" X-OriginalArrivalTime: 28 May 2010 11:22:55.0159 (UTC) FILETIME=[1E405470:01CAFE58] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #38: Decoupling routing metrics/constraintsfromObjective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 11:27:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01C9_01CAFE68.E11564D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01CA_01CAFE68.E11564D0" ------=_NextPart_001_01CA_01CAFE68.E11564D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi JP, On May 28, 2010, at 10:16 AM, Mathilde Durvy (mdurvy) wrote: Hi JP, [JP] There would be an OF specified along the lines on Section 10: 10. Guidelines for Objective Functions . . . . . . . . . . . . . . 59 And by the way, as you can see we do not specify the metrics in use. And the metrics/constraints would be specified independently using the DAG metric Container. A node could (if needed) add policy functions. Does that make sense ? Yes, so if I take the only example of OF given in Section 10 "minimize the path cost using the ETX metric and avoid 'Blue' links". Using the decoupling approach we would say something like "minimize the path cost as defined by the metric container and avoid links as specified by the constraint object". Correct? Absolutely. Do you agree with that plan ? Yes, it makes a lot of sense to me. Mathilde ------=_NextPart_001_01CA_01CAFE68.E11564D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi JP,

On May 28, 2010, at 10:16 AM, Mathilde Durvy (mdurvy) = wrote:
Hi JP,

 [JP]  There would be an = OF=20 specified along the lines on Section = 10: 
10. Guidelines for Objective Functions . . . = . . . . . .=20 . . . . . 59
And by the way, as = you can see we=20 do not specify the metrics in use.
And the = metrics/constraints would=20 be specified independently using the DAG metric = Container.
A node could (if = needed) add policy=20 functions.
Does that make sense = ?
 
Yes, so if I take the only = example of OF=20 given in Section=20 10  "minimize the path cost using the ETX metric and = avoid=20 'Blue' links".  Using the=20 decoupling approach we=20 would say something like "minimize the path cost as = defined by the=20 metric container and avoid links as specified by the constraint = object".=20 Correct?

Absolutely.

Do you agree with that plan ?

Yes, it=20 makes a lot of sense to me.
Mathilde
------=_NextPart_001_01CA_01CAFE68.E11564D0-- ------=_NextPart_000_01C9_01CAFE68.E11564D0 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDUyODExMjI1M1owIwYJKoZI hvcNAQkEMRYEFAqUV+UcR7ai/9SQQHtqKv/I8cYQMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAYK/i CK69TXu+DkfGZmcNixXOrL78a6S5LwAGGZENq1LuQsVmVAoTqk707LbnVDW4vfNjVhHs3PCvImQN MT+nGMi1crySx074Z95owG3TO/qxfoSriMxJWIK3Wd8hqbn6zILWudjE/IeIrN2N2OOCNDJ+sKdN BeBbrvpQaTRpGGQAAAAAAAA= ------=_NextPart_000_01C9_01CAFE68.E11564D0-- From robert.cragie@gridmerge.com Fri May 28 05:25:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6DE3A659B for ; Fri, 28 May 2010 05:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.873 X-Spam-Level: X-Spam-Status: No, score=0.873 tagged_above=-999 required=5 tests=[AWL=0.871, BAYES_50=0.001, HTML_MESSAGE=0.001, J_BACKHAIR_11=1, 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 BKKGCAgZey9P for ; Fri, 28 May 2010 05:24:28 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 1AC003A689E for ; Fri, 28 May 2010 05:20:13 -0700 (PDT) Received: from client-82-26-176-40.pete.adsl.virginmedia.com ([82.26.176.40] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OHyW3-0002cO-9L for roll@ietf.org; Fri, 28 May 2010 13:18:19 +0100 Message-ID: <4BFFB486.3040908@gridmerge.com> Date: Fri, 28 May 2010 13:18:14 +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 References: <87ocg1xgjf.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87ocg1xgjf.fsf@kelsey-ws.hq.ember.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070308000106040504080609" Subject: Re: [Roll] RPL ticket #32: Asymmetric Links - last call X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 12:25:32 -0000 This is a cryptographically signed message in MIME format. --------------ms070308000106040504080609 Content-Type: multipart/alternative; boundary="------------070607040500070605000300" This is a multi-part message in MIME format. --------------070607040500070605000300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I agree in principle. I'm not sure about the use of the words "down" and = "up" (and no I don't want to start that debate again, thank you). It's more a case of: Link A <-> B: Outgoing cost [A] -> B Incoming cost A -> [B] Outgoing cost A <- [B] Incoming cost [A] <- B where [] represents the subject of the cost measurement, i.e. the node=20 holding the measurement. 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 27/05/2010 8:59 PM, Richard Kelsey wrote: > Last chance to weigh in on ticket 32, before it is dropped > due to lack of interest. > > Note 1: This ticket is not concerned with asymmetric links in > general, but specifically with how path metrics are constructed > from asymmetric link metrics. > > Note 2: The ticket is against the RPL draft, but this is really > an issue for the routing metrics draft. > > > The problem: > > An asymmetric link metric can be used to create a number of > different path metrics, depending on how the upward and > downward link metrics are incorporated into the path metric. > The resulting path metric might reflect: > - the metric for messages travelling upward > - the metric for messages travelling downwards > - average of the upward and downward metrics > - best of the upward and downward metrics > - worst of the upward and downward metrics > and so on. > > Rather than try to encode all of the possible combining > functions, we can allow the inclusion of both the upward > and downward path metrics. > > A useful example here is latency in a network where nodes > wake up to receive messages on a fixed schedule. If nodes A > and B wake up to receive once a minute, with A waking up 5 > seconds before B, then the A->B link has a latency of 5 > seconds while B->A takes 55 seconds. If A chooses B as a > parent when building a DODAG that uses latency as a metric, > what value should it use for the latency of the A<->B link? > > > Proposal: > > Add a flag to Routing Metric/Constraint to indicate whether > the path metric represents the upward (flag =3D 0) or downward > (flag =3D 1) metric. The flag would only be meaningful for > path metrics that are aggregations of potentially asymmetric > link metrics, such as latency or link quality, > > A single DAG Metric Container would be allowed contain two > Routing Metric/Constraints of the same type, one containing > the upward path metric and the other having the downward. > > > Yes? No? > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > =20 --------------070607040500070605000300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree in principle. I'm not sure about the use of the words "down" and "up" (and no I don't want to start that debate again, thank you).
=
It's more a case of:

Link A <-> B:

Outgoing cost [A] -> B
Incoming cost A -> [B]
Outgoing cost A <- [B]
Incoming cost [A] <- B

where [] represents the subject of the cost measurement, i.e. the node holding the measurement.

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 27/05/2010 8:59 PM, Richard Kelsey wrote: 
Last chance to weigh in on ticket 32, before it is dropp=
ed
due to lack of interest.

Note 1: This ticket is not concerned with asymmetric links in
general, but specifically with how path metrics are constructed
from asymmetric link metrics.

Note 2: The ticket is against the RPL draft, but this is really
an issue for the routing metrics draft.


The problem:

An asymmetric link metric can be used to create a number of
different path metrics, depending on how the upward and
downward link metrics are incorporated into the path metric.
The resulting path metric might reflect:
  - the metric for messages travelling upward
  - the metric for messages travelling downwards
  - average of the upward and downward metrics
  - best of the upward and downward metrics
  - worst of the upward and downward metrics
and so on.

Rather than try to encode all of the possible combining
functions, we can allow the inclusion of both the upward
and downward path metrics.

A useful example here is latency in a network where nodes
wake up to receive messages on a fixed schedule.  If nodes A
and B wake up to receive once a minute, with A waking up 5
seconds before B, then the A->B link has a latency of 5
seconds while B->A takes 55 seconds.  If A chooses B as a
parent when building a DODAG that uses latency as a metric,
what value should it use for the latency of the A<->B link?


Proposal:

Add a flag to Routing Metric/Constraint to indicate whether
the path metric represents the upward (flag =3D 0) or downward
(flag =3D 1) metric.  The flag would only be meaningful for
path metrics that are aggregations of potentially asymmetric
link metrics, such as latency or link quality,

A single DAG Metric Container would be allowed contain two
Routing Metric/Constraints of the same type, one containing
the upward path metric and the other having the downward.


Yes?  No? =20
                             -Richard Kelsey
_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------070607040500070605000300-- --------------ms070308000106040504080609 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 MjgxMjE4MTRaMCMGCSqGSIb3DQEJBDEWBBSRdESkMkCdQJi541fnNjOLWdDvgTBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAGXJn5s87mW7xnb3YDHuhpp5x2k3xYSb5aJpZ1i1w/j5lt2i/mR9uKfNDihoebD6tnQ+ wyD6+an9JGuy83mUXVsoLHjvOOi4HpNAAwS24JH38GFMS5bFrHr5GmiE6TMt9dqopzK1z5UR W3rV/knoGeZA9SiQ4QBqnpwia3Lsuuu0XUtRO53r5nm/Jkyee1wdlg/onHB3XhFtP7rkwm8i EBza3nspfU1hhloTrpD5XgoYRt1WR3V1BjkKL/4k+JIjteMhV1FEtDQiCju1dxqqp3IzTb0J jsbX7MZu4/eAW8OyUJIH04RuzlK3XxeAVDBb+ABMDc/L7M/oMqRC3+BQ9EkAAAAAAAA= --------------ms070308000106040504080609-- From root@core3.amsl.com Fri May 28 14:45:03 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CA5A63A67B1; Fri, 28 May 2010 14:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100528214502.CA5A63A67B1@core3.amsl.com> Date: Fri, 28 May 2010 14:45:02 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-08.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 21:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-08.txt Pages : 92 Date : 2010-05-28 Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained: LLN routers typically operate with constraints on (any subset of) processing power, memory and energy (battery), and their interconnects are characterized by (any subset of) high loss rates, low data rates and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers, and support point-to-point traffic (between devices inside the LLN), point-to-multipoint traffic (from a central control point to a subset of devices inside the LLN) and multipoint- to-point traffic (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to- point traffic from devices inside the LLN towards a central control point, as well as point-to-multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-rpl-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-28143415.I-D@ietf.org> --NextPart-- From jpv@cisco.com Fri May 28 22:57:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909983A67EB for ; Fri, 28 May 2010 22:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.683 X-Spam-Level: X-Spam-Status: No, score=-9.683 tagged_above=-999 required=5 tests=[AWL=0.914, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 zRlK3yVBPh6I for ; Fri, 28 May 2010 22:57:12 -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 7A8943A6AB3 for ; Fri, 28 May 2010 22:57:12 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAMZJAEyrRN+J/2dsb2JhbACBP5x4caMhmVKFFQQ X-IronPort-AV: E=Sophos;i="4.53,322,1272844800"; d="scan'208,217";a="536990078" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 29 May 2010 05:57:02 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o4T5v1UZ003587; Sat, 29 May 2010 05:57:02 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 May 2010 07:57:00 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 May 2010 07:56:59 +0200 Message-Id: <4FB28FCE-50FF-4E38-BFB3-EA3F3E0CC3F9@cisco.com> From: JP Vasseur To: "roll@ietf.org WG" , Tim Winter , seclln@external.cisco.com Content-Type: multipart/alternative; boundary=Apple-Mail-625-452675322 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 29 May 2010 07:56:58 +0200 References: <20100528214502.CA5A63A67B1@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 May 2010 05:57:00.0359 (UTC) FILETIME=[C1186570:01CAFEF3] Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-rpl-08.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 05:57:13 -0000 --Apple-Mail-625-452675322 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, Tim will provide you a detailed update on the changes in this version of RPL, several tickets will be closed. Security Design Team, could you provide a summary on your end (what is covered, what remains and will be covered in 09) ? Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: May 28, 2010 11:45:02 PM CEDT > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: [Roll] I-D Action:draft-ietf-roll-rpl-08.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and > Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-08.txt > Pages : 92 > Date : 2010-05-28 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained: LLN routers > typically operate with constraints on (any subset of) processing > power, memory and energy (battery), and their interconnects are > characterized by (any subset of) high loss rates, low data rates and > instability. LLNs are comprised of anything from a few dozen and up > to thousands of routers, and support point-to-point traffic (between > devices inside the LLN), point-to-multipoint traffic (from a central > control point to a subset of devices inside the LLN) and multipoint- > to-point traffic (from devices inside the LLN towards a central > control point). This document specifies the IPv6 Routing Protocol > for LLNs (RPL), which provides a mechanism whereby multipoint-to- > point traffic from devices inside the LLN towards a central control > point, as well as point-to-multipoint traffic from the central > control point to the devices inside the LLN, is supported. Support > for point-to-point traffic is also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-625-452675322 Content-Type: multipart/mixed; boundary=Apple-Mail-626-452675322 --Apple-Mail-626-452675322 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = all,

Tim will provide you a detailed update on the = changes in this version of RPL, several 
tickets will be = closed.

Security Design Team, could you provide = a summary on your end (what is covered, what
remains and will = be covered in 09) = ?

Thanks.

JP.
Begin forwarded message:

Date: May 28, 2010 11:45:02 PM = CEDT
To: i-d-announce@ietf.org
Subject: = [Roll] I-D = Action:draft-ietf-roll-rpl-08.txt

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Routing Over Low power = and Lossy networks Working Group of the IETF.


Title =           : RPL: IPv6 = Routing Protocol for Low power and Lossy Networks
Author(s) =       : T. Winter, et al.
Filename =        : = draft-ietf-roll-rpl-08.txt
Pages =           : = 92
= Date =            : = 2010-05-28

Low power and Lossy Networks (LLNs) are a class of = network in which
both the routers and their interconnect are = constrained: LLN routers
typically operate with constraints on (any = subset of) processing
power, memory and energy (battery), and their = interconnects are
characterized by (any subset of) high loss rates, = low data rates and
instability.  LLNs are comprised of anything = from a few dozen and up
to thousands of routers, and support = point-to-point traffic (between
devices inside the LLN), = point-to-multipoint traffic (from a central
control point to a subset = of devices inside the LLN) and multipoint-
to-point traffic (from = devices inside the LLN towards a central
control point).  This = document specifies the IPv6 Routing Protocol
for LLNs (RPL), which = provides a mechanism whereby multipoint-to-
point traffic from = devices inside the LLN towards a central control
point, as well as = point-to-multipoint traffic from the central
control point to the = devices inside the LLN, is supported.  Support
for = point-to-point traffic is also available.

A URL for this = Internet-Draft is:
ht= tp://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-08.txt

In= ternet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-626-452675322 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2010-05-28143415.I-D@ietf.org>

--Apple-Mail-626-452675322 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--Apple-Mail-626-452675322-- --Apple-Mail-625-452675322-- From trac@tools.ietf.org Fri May 28 23:01:43 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6CE23A6816 for ; Fri, 28 May 2010 23:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.125 X-Spam-Level: X-Spam-Status: No, score=-100.125 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_40=-0.185, 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 ubi8yQqMh7NB for ; Fri, 28 May 2010 23:01:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0093A3A67EB for ; Fri, 28 May 2010 23:01:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OIF6x-0005af-7u; Fri, 28 May 2010 23:01:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Sat, 29 May 2010 06:01:31 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/28#comment:1 Message-ID: <064.5152628e75a4f73be5f91422ef16ea26@tools.ietf.org> References: <055.c8b369fc6d851e8e67a30bbedc694225@tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <055.c8b369fc6d851e8e67a30bbedc694225@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@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: roll@ietf.org Subject: Re: [Roll] [roll] #28: Remove the Trickle Section from RPL specification X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 06:01:43 -0000 #28: Remove the Trickle Section from RPL specification --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: task | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Trickle is now a separate document listed as a reference in the RPL ID: [I-D.ietf-roll-trickle] Levis, P., Clausen, T., Hui, J., and J. Ko, "The Trickle Algorithm", draft-ietf-roll-trickle-01 (work in progress), April 2010. -- Ticket URL: roll From trac@tools.ietf.org Fri May 28 23:03:26 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8083A6835 for ; Fri, 28 May 2010 23:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.341 X-Spam-Level: X-Spam-Status: No, score=-101.341 tagged_above=-999 required=5 tests=[AWL=1.259, 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 d8l0pclF7Lqy for ; Fri, 28 May 2010 23:03:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AFBF73A67EB for ; Fri, 28 May 2010 23:03:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OIF8b-0005eU-RB; Fri, 28 May 2010 23:03:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Sat, 29 May 2010 06:03:13 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/40 Message-ID: <055.875cf6ea70c901de39b3a99b6a3575c0@tools.ietf.org> X-Trac-Ticket-ID: 40 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@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: roll@ietf.org Subject: [Roll] [roll] #40: Appendix A can be removed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 06:03:26 -0000 #40: Appendix A can be removed --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Since requirements are tracked in a separate ticket. -- Ticket URL: roll From trac@tools.ietf.org Fri May 28 23:05:15 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255613A6835 for ; Fri, 28 May 2010 23:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.569 X-Spam-Level: X-Spam-Status: No, score=-100.569 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_20=-0.74, 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 G1YTtU4Kt48U for ; Fri, 28 May 2010 23:05:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5F9B03A6816 for ; Fri, 28 May 2010 23:05:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OIFAO-0005fu-7q; Fri, 28 May 2010 23:05:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Sat, 29 May 2010 06:05:04 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/29#comment:1 Message-ID: <064.60b0affa64d3caabf34210aadbac7af9@tools.ietf.org> References: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@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: roll@ietf.org Subject: Re: [Roll] [roll] #29: DIS packet format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 06:05:15 -0000 #29: DIS packet format --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: task | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Here is the new format, which allows to close this ticket: 5.2. DODAG Information Solicitation (DIS) The DODAG Information Solicitation (DIS) message may be used to solicit a DODAG Information Object from a RPL node. Its use is analogous to that of a Router Solicitation as specified in IPv6 Neighbor Discovery; a node may use DIS to probe its neighborhood for nearby DODAGs. Section 6.3 describes how nodes respond to a DIS. 5.2.1. Format of the DIS Base Object 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: The DIS Base Object Winter, et al. Expires November 29, 2010 [Page 26] Internet-Draft draft-ietf-roll-rpl-08 May 2010 Unassigned bits of the DIS Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. -- Ticket URL: roll From trac@tools.ietf.org Fri May 28 23:07:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AFBB3A6981 for ; Fri, 28 May 2010 23:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.218 X-Spam-Level: X-Spam-Status: No, score=-100.218 tagged_above=-999 required=5 tests=[AWL=-0.218, 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 Q0qJxWA65qf1 for ; Fri, 28 May 2010 23:07:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0987A3A6835 for ; Fri, 28 May 2010 23:07:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OIFCc-0005t2-La; Fri, 28 May 2010 23:07:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Sat, 29 May 2010 06:07:22 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/30#comment:1 Message-ID: <064.586bca462578be2fb7902ab190d582fc@tools.ietf.org> References: <055.d2eab2c729c6835d4457709ee6cb8117@tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <055.d2eab2c729c6835d4457709ee6cb8117@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@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: roll@ietf.org Subject: Re: [Roll] [roll] #30: Clearly documenting Multicast mode of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 06:07:34 -0000 #30: Clearly documenting Multicast mode of operation --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: task | Status: closed Priority: minor | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Multicast operation is now clearly documented in revision 08: 9. Multicast Operation This section describes further the multicast routing operations over an IPv6 RPL network, and specifically how unicast DAOs can be used to relay group registrations up. Wherever the following text mentions Multicast Listener Discovery (MLD), one can read MLDv1 ([RFC2710]) or MLDv2 ([RFC3810]). As is traditional, a listener uses a protocol such as MLD with a router to register to a multicast group. Along the path between the router and the DODAG root, MLD requests are mapped and transported as DAO messages within the RPL protocol; each hop coalesces the multiple requests for a same group as a single DAO message to the parent(s), in a fashion similar to proxy IGMP, but Winter, et al. Expires November 29, 2010 [Page 68] Internet-Draft draft-ietf-roll-rpl-08 May 2010 recursively between child router and parent up to the root. A router might select to pass a listener registration DAO message to its preferred parent only, in which case multicast packets coming back might be lost for all of its sub-DODAG if the transmission fails over that link. Alternatively the router might select to copy additional parents as it would do for DAO messages advertising unicast destinations, in which case there might be duplicates that the router will need to prune. As a result, multicast routing states are installed in each router on the way from the listeners to the root, enabling the root to copy a multicast packet to all its children routers that had issued a DAO message including a DAO for that multicast group, as well as all the attached nodes that registered over MLD. For unicast traffic, it is expected that the grounded root of an DODAG terminates RPL and MAY redistribute the RPL routes over the external infrastructure using whatever routing protocol is used in the other routing domain. For multicast traffic, the root MAY proxy MLD for all the nodes attached to the RPL domain (this would be needed if the multicast source is located in the external infrastructure). For such a source, the packet will be replicated as it flows down the DODAG based on the multicast routing table entries installed from the DAO message. For a source inside the DODAG, the packet is passed to the preferred parents, and if that fails then to the alternates in the DODAG. The packet is also copied to all the registered children, except for the one that passed the packet. Finally, if there is a listener in the external infrastructure then the DODAG root has to further propagate the packet into the external infrastructure. As a result, the DODAG Root acts as an automatic proxy Rendezvous Point for the RPL network, and as source towards the Internet for all multicast flows started in the RPL LLN. So regardless of whether the root is actually attached to the Internet, and regardless of whether the DODAG is grounded or floating, the root can serve inner multicast streams at all times. -- Ticket URL: roll From trac@tools.ietf.org Fri May 28 23:08:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCC93A6816 for ; Fri, 28 May 2010 23:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.496 X-Spam-Level: X-Spam-Status: No, score=-101.496 tagged_above=-999 required=5 tests=[AWL=1.104, 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 A9rPHExnUqq1 for ; Fri, 28 May 2010 23:08:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 18A4C3A67D9 for ; Fri, 28 May 2010 23:08:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OIFDk-0005ti-Ee; Fri, 28 May 2010 23:08:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Sat, 29 May 2010 06:08:32 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/34#comment:1 Message-ID: <064.c19cdf05267255b0945b50a094fd932e@tools.ietf.org> References: <055.14d6d303cd779ec9182b0da05a59822b@tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <055.14d6d303cd779ec9182b0da05a59822b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@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: roll@ietf.org Subject: Re: [Roll] [roll] #34: Move example to a separate ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 06:08:44 -0000 #34: Move example to a separate ID --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: task | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Examples have been removed in revision 08 -- Ticket URL: roll From jpv@cisco.com Fri May 28 23:28:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32663A67EB for ; Fri, 28 May 2010 23:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.467 X-Spam-Level: X-Spam-Status: No, score=-9.467 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, 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 WkB4No7yERnA for ; Fri, 28 May 2010 23:28:28 -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 DA8153A67D9 for ; Fri, 28 May 2010 23:28:27 -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: AvsEAM5QAExAZnwN/2dsb2JhbACeOXGjSJlVhRUE X-IronPort-AV: E=Sophos;i="4.53,322,1272844800"; d="scan'208";a="116030208" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 May 2010 06:28:17 +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 o4T6SGNu009649 for ; Sat, 29 May 2010 06:28:16 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 May 2010 08:28:16 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 May 2010 08:28:15 +0200 Message-Id: <0DE37708-A32C-43F4-A693-A926F8547D5A@cisco.com> From: JP Vasseur To: "roll@ietf.org WG" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 29 May 2010 08:28:15 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 May 2010 06:28:15.0991 (UTC) FILETIME=[1F0F2070:01CAFEF8] Subject: [Roll] Virtual Blue Sheet X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 06:28:28 -0000 If you attend the Virtual ROLL WG meeting on June 16, please sign a virtual blue sheet (just send me an email with the following format: name,email Thanks JP. From jpv@cisco.com Fri May 28 23:28:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0193A6A99; Fri, 28 May 2010 23:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.211 X-Spam-Level: X-Spam-Status: No, score=-8.211 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, 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 pjsTRuHQTu0E; Fri, 28 May 2010 23:28:32 -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 074B53A69FE; Fri, 28 May 2010 23:28:32 -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: AvsEAM5QAEyrR7Ht/2dsb2JhbACeOXGIMJsYmVWCZREGghkEj1U X-IronPort-AV: E=Sophos;i="4.53,322,1272844800"; d="scan'208,217";a="204576793" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 29 May 2010 06:28:21 +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 o4T6SLCT019584; Sat, 29 May 2010 06:28:21 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 May 2010 08:27:19 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 May 2010 08:27:19 +0200 Message-Id: <7C95D13E-558D-4974-ABEB-5E33808E45F6@cisco.com> From: JP Vasseur To: "roll@ietf.org WG" Content-Type: multipart/alternative; boundary=Apple-Mail-635-454494663 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 29 May 2010 08:27:17 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 May 2010 06:27:19.0412 (UTC) FILETIME=[FD55DB40:01CAFEF7] Cc: ietf-secretary@ietf.org Subject: [Roll] Agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 06:28:33 -0000 --Apple-Mail-635-454494663 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, Please find below the agenda for the ROL virtual WG meeting that will take place on June 16 at 8:00 PDT (as a reminder, please find attach the bridge number). If you plan to attend. Here is the agenda: Agenda/admin (Chairs - 5mn) [5] 1) WG Status (Chairs - 5 mn) [10] 2) RPL: Routing Protocol for Low power and Lossy networks (TBC - 45 mn) [55] draft-ietf-roll-rpl 3) Mechanisms to Support Point-to-Point Routing in Low Power and Lossy Networks (TBC - 45mn ) [90] draft-dt-roll-p2p-rpl 4) The ETX Objective Function for RPL (Omprakash- 5mn) [95] draft-gnawali-roll-etxof 5) Discussion on decoupling OF/metric (to be confirmed) Bridge Details Topic: Roll Virtual WG Meeting Date: Wednesday, June 16, 2010 Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 208 016 618 Password: roll18 ------------------------------------------------------- To join the meeting online(Now from iPhones and other Smartphones too!) ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=140856737&UID=484302782&PW=NYTUxNTcxNWNh 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: roll18 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that appear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:208 016 618 Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial CCP:+14085256800x208016618# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. Thanks. JP. --Apple-Mail-635-454494663 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = all,

Please find below the agenda for the ROL virtual = WG meeting that will take place on June 16 at 8:00 PDT (as a reminder, = please find attach the bridge number).

If you = plan to attend.

Here is the = agenda:

Agenda/admin (Chairs - 5mn) = [5]

1) WG Status (Chairs - 5 mn) = [10]

2) RPL: Routing Protocol for Low power and = Lossy networks (TBC - 45 mn) = [55]
draft-ietf-roll-rpl

3) = Mechanisms to Support Point-to-Point Routing in Low Power and Lossy = Networks
(TBC - 45mn ) [90] = draft-dt-roll-p2p-rpl

4) The ETX Objective = Function for RPL (Omprakash- 5mn) = [95]
draft-gnawali-roll-etxof

5) = Discussion on decoupling OF/metric (to be = confirmed)

Bridge = Details

Topic: Roll Virtual WG Meeting 
Date: = Wednesday, June 16, 2010 
Time: 8:00 am, Pacific Daylight Time = (San Francisco, GMT-07:00) 
Meeting Number: 208 016 = 618 
Password: = roll18 

------------------------------------------------------= - 
To join the meeting online(Now from iPhones and other = Smartphones = too!) 
-------------------------------------------------------&nbs= p;
1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D14085= 6737&UID=3D484302782&PW=3DNYTUxNTcxNWNh 
2. If = requested, enter your name and email address. 
3. If a password = is required, enter the meeting password: roll18 
4. Click = "Join". 
5. If the meeting includes a teleconference, follow the = instructions that appear on your = screen. 

-----------------------------------------------------= -- 
To join the audio conference = only 
------------------------------------------------------- = ;
To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access = code. 
Call-in toll-free number (US/Canada): = +1-866-432-9903 
Call-in toll number (US/Canada): = +1-408-525-6800 
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf&n= bsp;

Access code:208 016 618 

Sign up for a free = trial of WebEx 
http://www.webex.com/go/mcemfreetrial 

C= CP:+14085256800x208016618# 

IMPORTANT NOTICE: This WebEx = service includes a feature that allows audio and any documents and other = materials exchanged or viewed during the session to be recorded. By = joining this session, you automatically consent to such recordings. If = you do not consent to the recording, do not join the = session. 


Thanks.

JP.
= --Apple-Mail-635-454494663-- From jpv@cisco.com Fri May 28 23:32:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0741A3A69F3 for ; Fri, 28 May 2010 23:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.749 X-Spam-Level: X-Spam-Status: No, score=-9.749 tagged_above=-999 required=5 tests=[AWL=0.850, 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 oSCd4e6LlQjc for ; Fri, 28 May 2010 23:32:33 -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 12D3D3A684B for ; Fri, 28 May 2010 23:32:32 -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: AvsEAPxRAExAZnwN/2dsb2JhbACeOXGjRJlVhRUE X-IronPort-AV: E=Sophos;i="4.53,322,1272844800"; d="scan'208";a="116030960" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 May 2010 06:32:22 +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 o4T6WMRn010644 for ; Sat, 29 May 2010 06:32:22 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 May 2010 08:32:21 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 May 2010 08:32:21 +0200 Message-Id: <2AB83DFF-F73C-4130-BE55-F4033056816B@cisco.com> From: JP Vasseur To: "roll@ietf.org WG" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 29 May 2010 08:32:20 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 May 2010 06:32:21.0445 (UTC) FILETIME=[B15C6F50:01CAFEF8] Subject: [Roll] Cut-off dates and slides for the Virtual WG meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 06:32:34 -0000 Dear all, If you have a slot during the Virtual ROLL WG meeting please: 1) Post the latest revision of your ID by June 11 2) Send the slides to the chair by June 11 (this is really important especially for such virtual meetings). Thanks. JP. From jpv@cisco.com Sun May 30 01:00:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A3C3A67A5 for ; Sun, 30 May 2010 01:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.81 X-Spam-Level: X-Spam-Status: No, score=-9.81 tagged_above=-999 required=5 tests=[AWL=0.789, 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 pbV6gWXkAnum for ; Sun, 30 May 2010 01:00:11 -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 EF1B33A67AD for ; Sun, 30 May 2010 01:00: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: AvsEAGe3AUyrR7Ht/2dsb2JhbACeNHGjXZhMhRYE X-IronPort-AV: E=Sophos;i="4.53,327,1272844800"; d="scan'208";a="537308785" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 30 May 2010 08:00:00 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4U7xxnX012130; Sun, 30 May 2010 08:00:00 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 May 2010 09:59:58 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 May 2010 09:59:58 +0200 Message-Id: From: JP Vasseur To: ROLL WG In-Reply-To: <6477E121-6289-4868-A443-E0113B5267A2@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 09:59:56 +0200 References: <20100526184121.2F0763A68D6@core3.amsl.com> <6477E121-6289-4868-A443-E0113B5267A2@archrock.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 30 May 2010 07:59:58.0378 (UTC) FILETIME=[192680A0:01CAFFCE] Subject: Re: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 08:00:11 -0000 If you have any comment on that simple draft, let us know by end of this week. Then in the absence of opposition I'll close the ticket #35, since the draft will be discussed in 6man WG and will only be reference in the RPL specification. On May 27, 2010, at 6:20 PM, Jonathan Hui wrote: > > To address RPL ticket #35, we submitted a draft to 6man that > proposes a new IPv6 routing header to support source routing in non- > storing mode. > > Some high-level details: > - Format is derived from RH0 > - Format is extended to support simple compression of IPv6 address > entries within the routing header > - Use of the RPL routing header is constrained to a RPL domain. > > http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-00 > > Comments appreciated as always. > > -- > Jonathan Hui > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: May 26, 2010 11:41:21 AM PDT >> To: jhui@archrock.com >> Cc: jpv@cisco.com,culler@cs.berkeley.edu >> Subject: New Version Notification for draft-hui-6man-rpl-routing- >> header-00 >> >> >> A new version of I-D, draft-hui-6man-rpl-routing-header-00.txt has >> been successfully submitted by Jonathan Hui and posted to the IETF >> repository. >> >> Filename: draft-hui-6man-rpl-routing-header >> Revision: 00 >> Title: A Source Routing Header for RPL >> Creation_date: 2010-05-26 >> WG ID: Independent Submission >> Number_of_pages: 13 >> >> Abstract: >> In Low power and Lossy Networks (LLNs), memory constraints on routers >> may limit them to maintaining at most a few routes. In some >> configurations, it is necessary to use these memory constrained >> routers to deliver datagrams to nodes within the LLN. The Routing >> for Low Power and Lossy Networks (RPL) protocol can be used in some >> deployments to store most, if not all, routes on one (e.g. the >> Directed Acyclic Graph (DAG) root) or few routers and forward the >> IPv6 datagram using a source routing technique to avoid large routing >> tables on memory constrained routers. This document specifies a new >> IPv6 Routing header type for delivering datagrams within a RPL >> domain. >> >> >> >> The IETF Secretariat. >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Sun May 30 01:01:40 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B113A67AD for ; Sun, 30 May 2010 01:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.862 X-Spam-Level: X-Spam-Status: No, score=-9.862 tagged_above=-999 required=5 tests=[AWL=0.736, 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 X+GKh5LxAkS1 for ; Sun, 30 May 2010 01:01:39 -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 553D83A67A5 for ; Sun, 30 May 2010 01:01:39 -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: Av0EAM64AUyrRN+K/2dsb2JhbACBPpx2caNmmE2CX4I3BA X-IronPort-AV: E=Sophos;i="4.53,327,1272844800"; d="scan'208,217";a="137023925" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 30 May 2010 08:01:28 +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 o4U81R0P018457; Sun, 30 May 2010 08:01:28 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 May 2010 10:01:27 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 May 2010 10:01:26 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-662-546541863 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 10:01:25 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 30 May 2010 08:01:26.0764 (UTC) FILETIME=[4DD522C0:01CAFFCE] Subject: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-option-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 08:01:40 -0000 --Apple-Mail-662-546541863 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Sane comment here: If you have any comment on that simple draft, let us know by end of this week. Then in the absence of opposition I'll close the ticket #21, since the draft will be discussed in 6man WG and will only be reference in the RPL specification. Begin forwarded message: > From: JP Vasseur > Date: May 17, 2010 3:18:24 PM CEDT > To: ipv6@ietf.org > Subject: Fwd: New Version Notification for draft-hui-6man-rpl- > option-00.txt > > Dear all, > > This is to re-activate our discussion during the last IETF meetings. > Feed-back are very welcome since we would like to move forward as > soon as possible, this proposed extension is indeed critical for RPL > to move forward. > > Many Thanks. > > JP and Jonathan. > > Begin forwarded message: > >> From: Jonathan Hui >> Date: March 12, 2010 6:39:40 PM CEST >> To: ipv6@ietf.org >> Cc: "JP Vasseur (jvasseur)" >> Subject: New Version Notification for draft-hui-6man-rpl- >> option-00.txt >> >> >> Hi, >> >> We are working on a new routing protocol (called RPL) within the >> ROLL WG targeted at low-power and lossy networks (LLNs). Designed >> to operate within resource constraints typical to LLNs, RPL uses a >> slow proactive process to construct and maintain a routing topology >> but a reactive and dynamic approach to resolving routing >> inconsistencies. In short, RPL is designed to utilize routing >> information placed within data-plane datagrams to detect routing >> inconsistencies. To carry RPL routing information within a RPL >> routing domain, we would like to define a new IPv6 Option to be >> carried within the IPv6 Hop-by-Hop Option header. >> >> Any comments are appreciated. >> >> >> Filename: draft-hui-6man-rpl-option >> Revision: 00 >> Title: RPL Option for Carrying RPL Information in Data-Plane >> Datagrams >> Creation_date: 2010-03-01 >> WG ID: Independent Submission >> Number_of_pages: 6 >> >> Abstract: >> The RPL protocol requires data-plane datagrams to carry RPL routing >> information that is processed by RPL routers when forwarding those >> datagrams. This document describes the RPL option for use within a >> RPL domain. >> >> -- >> Jonathan Hui >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-662-546541863 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sane comment = here:

If you have any comment on that simple draft, = let us know by end of this week. Then in the absence of = opposition
I'll close the ticket #21, since the draft will be = discussed in 6man WG and will only be reference in the RPL = specification.


Begin forwarded = message:

From: JP Vasseur <jpv@cisco.com>
Date: = May 17, 2010 3:18:24 PM CEDT
Subject: = Fwd: New Version Notification for = draft-hui-6man-rpl-option-00.txt

Dear all,

This is to re-activate = our discussion during the last IETF meetings. Feed-back are very welcome = since we would like to move forward as soon as possible, this proposed = extension is indeed critical for RPL to move = forward.

Many = Thanks.

JP and Jonathan.

Begin = forwarded message:

From: = Jonathan Hui <jhui@archrock.com>
Date: = March 12, 2010 6:39:40 PM CEST
Cc: "JP = Vasseur (jvasseur)" <jvasseur@cisco.com>
=
Subject: = New Version Notification for = draft-hui-6man-rpl-option-00.txt


Hi,

We are working = on a new routing protocol (called RPL) within the ROLL WG targeted at = low-power and lossy networks (LLNs).  Designed to operate within = resource constraints typical to LLNs, RPL uses a slow proactive process = to construct and maintain a routing topology but a reactive and dynamic = approach to resolving routing inconsistencies.  In short, RPL is = designed to utilize routing information placed within data-plane = datagrams to detect routing inconsistencies.  To carry RPL routing = information within a RPL routing domain, we would like to define a new = IPv6 Option to be carried within the IPv6 Hop-by-Hop Option = header.

Any comments are appreciated.


Filename: = draft-hui-6man-rpl-option
Revision: 00
Title: RPL = Option for Carrying RPL Information in Data-Plane = Datagrams
Creation_date: 2010-03-01
WG ID: = Independent Submission
Number_of_pages: 6

Abstract:
The RPL = protocol requires data-plane datagrams to carry RPL routing information = that is processed by RPL routers when forwarding those datagrams. This = document describes the RPL option for use within a RPL = domain.

--
Jonathan = Hui


----------------------= ----------------------------------------------
IETF IPv6 working = group mailing list
ipv6@ietf.org
Administrative = Requests: = https://www.ietf.org/mailman/listinfo/ipv6
----------------------------= ----------------------------------------

<= /body>= --Apple-Mail-662-546541863-- From pthubert@cisco.com Sun May 30 23:54:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D62E53A6939 for ; Sun, 30 May 2010 23:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.833 X-Spam-Level: X-Spam-Status: No, score=-7.833 tagged_above=-999 required=5 tests=[AWL=0.907, 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 pqL0SguMqRTU for ; Sun, 30 May 2010 23:54:33 -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 968303A67EC for ; Sun, 30 May 2010 23:54:33 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,331,1272844800"; d="scan'208";a="116438011" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 31 May 2010 06:54:21 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4V6sKG2005044; Mon, 31 May 2010 06:54:21 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:54:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 31 May 2010 08:54:18 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02015AB5@XMB-AMS-107.cisco.com> In-Reply-To: <055.f20158b4ed882efacedace4b6140209d@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [roll] #39: RPL option lenght Thread-Index: Acr9fhT/n7UPgGtqRayS2A4ToJITVwDD3xCA References: <055.f20158b4ed882efacedace4b6140209d@tools.ietf.org> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 31 May 2010 06:54:20.0890 (UTC) FILETIME=[18A343A0:01CB008E] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #39: RPL option lenght X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 06:54:35 -0000 SGkgSlANCg0KSSB0aGluayB3ZSBjYW4gY2xvc2UgdGhpcyBvbmUuIFRoZSAwOCBzcGVjIGhhczoN Ci0gcmVzdG9yZWQgdGhlIHNpemUgdG8gMSBvY3RldCBleHByZXNzZWQgaW4gYnl0ZXMNCi0gaW5j bHVkZWQgTkQncyBSSU8gYW5kIERJTyBidXQgd2l0aCBhIGRpZmZlcmVudCB0eXBlIGFuZCBsZW5n dGggdG8gbWF0Y2ggdGhlIHJlc3Qgb2YgUlBMLg0KDQpUaGUgbGFzdCBxdWVzdGlvbiBpbiBteSBt aW5kIGlzIHdoZXRoZXIgd2Ugc2hvdWxkIGFsc28gaW5jbHVkZSB0aGUgU0xMQSBhbmQgTVRVIG9w dGlvbnMuIE1ha2Ugc2Vuc2UgdG8gbWUgYW5kIGdvdCBwb3NpdGl2ZSBhbnN3ZXJzIG9uIHRoZSBN TC4NCg0KUGFzY2FsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBy b2xsIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjQHRvb2xzLmlldGYub3JnXQ0KPiBTZW50OiBU aHVyc2RheSwgTWF5IDI3LCAyMDEwIDExOjIxIEFNDQo+IFRvOiBQYXNjYWwgVGh1YmVydCAocHRo dWJlcnQpOyBqcHZAY2lzY28uY29tDQo+IENjOiByb2xsQGlldGYub3JnDQo+IFN1YmplY3Q6IFty b2xsXSAjMzk6IFJQTCBvcHRpb24gbGVuZ2h0DQo+IA0KPiAjMzk6IFJQTCBvcHRpb24gbGVuZ2h0 DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gIFJlcG9ydGVyOiAganB2QOKApiAgICAgICAgICAg ICAgIHwgICAgICAgT3duZXI6ICBwdGh1YmVydEDigKYNCj4gICAgICBUeXBlOiAgZGVmZWN0ICAg ICAgICAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3DQo+ICBQcmlvcml0eTogIG1ham9yICAgICAg ICAgICAgICAgfCAgIE1pbGVzdG9uZToNCj4gQ29tcG9uZW50OiAgcnBsICAgICAgICAgICAgICAg ICB8ICAgICBWZXJzaW9uOg0KPiAgU2V2ZXJpdHk6ICBBY3RpdmUgV0cgRG9jdW1lbnQgIHwgICAg S2V5d29yZHM6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gIEZyb206IHJvbGwtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ICAgPiBP Zg0KPiAgID4+IE1hdHRlbyBQYXJpcw0KPiAgID4+IFNlbnQ6IFR1ZXNkYXksIE1heSAyNSwgMjAx MCA1OjAyIFBNDQo+ICAgPj4gVG86IHJvbGxAaWV0Zi5vcmcNCj4gICA+PiBTdWJqZWN0OiBbUm9s bF0gUlBMIG9wdGlvbiBsZW5ndGgNCj4gICA+Pg0KPiAgID4+DQo+ICAgPj4gVGhlIFJQTCBvcHRp b24gbGVuZ3RoIGZpZWxkIGlzIDIgYnl0ZXMgbG9uZy4gIEkgcHJvcG9zZSB3ZSBjaGFuZ2UgaXQN Cj4gICA+IHRvIDEgYnl0ZS4NCj4gICA+PiBGb3IgY29tcGFyaXNvbiwgdGhlIElQdjYgYW5kIE5E IG9wdGlvbiBsZW5ndGggZmllbGRzIGFyZQ0KPiAgID4+IDEgYnl0ZSBsb25nLiAgU2luY2UgUlBM IGlzIGJlaW5nIGRlc2lnbmVkIGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLA0KPiAgID4gdGhlcmUg d29uJ3QNCj4gICA+PiBiZSBhIG5lZWQgZm9yIG9wdGlvbnMgYmlnZ2VyIHRoYW4gSVB2NiBhbmQg TkQgb3B0aW9ucy4NCj4gICA+Pg0KPiAgID4+IElmIHlvdSBhZ3JlZSwgcGxlYXNlIHNlbmQgYSBx dWljayArMSB0byB0aGUgbGlzdCBpbiByZXBseSBzbyB3ZSBjYW4NCj4gICA+IG1vdmUgdGhpcw0K PiAgID4+IHNtYWxsIG1hdHRlciBmb3J3YXJkIHRvIGEgdGlja2V0Lg0KPiAgID4+DQo+ICAgPj4g VGhhbmtzLA0KPiAgID4+IE1hdHRlbw0KPiANCj4gLS0NCj4gVGlja2V0IFVSTDogPGh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL3dnL3JvbGwvdHJhYy90aWNrZXQvMzk+DQo+IHJvbGwgPGh0dHA6 Ly90b29scy5pZXRmLm9yZy93Zy9yb2xsLz4NCg0K From trac@tools.ietf.org Sun May 30 23:59:27 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA853A687D for ; Sun, 30 May 2010 23:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.95 X-Spam-Level: X-Spam-Status: No, score=-101.95 tagged_above=-999 required=5 tests=[AWL=0.650, 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 XLwHnW-+ahdR for ; Sun, 30 May 2010 23:59:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6BB733A67EC for ; Sun, 30 May 2010 23:59:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OIyxv-0001RS-2C; Sun, 30 May 2010 23:59:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Mon, 31 May 2010 06:59:15 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/41 Message-ID: <055.7153d5eea23badb3dd1cdb82fdf0a90a@tools.ietf.org> X-Trac-Ticket-ID: 41 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@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: roll@ietf.org Subject: [Roll] [roll] #41: Adding the SLLA and MTU options in the RPL spec ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 06:59:27 -0000 #41: Adding the SLLA and MTU options in the RPL spec ? --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: new Priority: minor | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Title self descriptive -- Ticket URL: roll From trac@tools.ietf.org Mon May 31 00:00:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4FD3A6988 for ; Mon, 31 May 2010 00:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.983 X-Spam-Level: X-Spam-Status: No, score=-101.983 tagged_above=-999 required=5 tests=[AWL=0.617, 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 3FiehJldEyED for ; Mon, 31 May 2010 00:00:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D67763A67EC for ; Mon, 31 May 2010 00:00:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OIyyz-0001Zd-WC; Mon, 31 May 2010 00:00:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Mon, 31 May 2010 07:00:21 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/39#comment:1 Message-ID: <064.0c482f1eafe33ffd9959ac89219d27e3@tools.ietf.org> References: <055.f20158b4ed882efacedace4b6140209d@tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <055.f20158b4ed882efacedace4b6140209d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@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: roll@ietf.org Subject: Re: [Roll] [roll] #39: RPL option lenght X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 07:00:33 -0000 #39: RPL option lenght --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Consensus on the mailing list: In revision 08: - restored the size to 1 octet expressed in bytes - included ND's RIO and DIO but with a different type and length to match the rest of RPL. -- Ticket URL: roll From jpv@cisco.com Mon May 31 00:05:40 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70AC3A69B9 for ; Mon, 31 May 2010 00:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.908 X-Spam-Level: X-Spam-Status: No, score=-9.908 tagged_above=-999 required=5 tests=[AWL=0.691, 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 O+7Nbjuc17nX for ; Mon, 31 May 2010 00:05:39 -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 BB7723A6988 for ; Mon, 31 May 2010 00:05:38 -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: AvsEALj8AkxAaHte/2dsb2JhbACeMnGmQJkVhRYE X-IronPort-AV: E=Sophos;i="4.53,331,1272844800"; d="scan'208";a="330732961" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-1.cisco.com with ESMTP; 31 May 2010 07:05:27 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4V755VH010742 for ; Mon, 31 May 2010 07:05:26 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 09:05:23 +0200 Received: from ams-jvasseur-8717.cisco.com ([10.55.201.136]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 09:05:23 +0200 Message-Id: <9BEF6AA0-FDE6-4B92-AAB0-F5D2C7CCBBCE@cisco.com> From: JP Vasseur To: ROLL WG , "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02015AB5@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 31 May 2010 09:05:22 +0200 References: <055.f20158b4ed882efacedace4b6140209d@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D02015AB5@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 31 May 2010 07:05:23.0732 (UTC) FILETIME=[A3B8ED40:01CB008F] Subject: Re: [Roll] [roll] #39: RPL option lenght X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 07:05:40 -0000 Hi Pa On May 31, 2010, at 8:54 AM, Pascal Thubert (pthubert) wrote: > Hi JP > > I think we can close this one. The 08 spec has: > - restored the size to 1 octet expressed in bytes > - included ND's RIO and DIO but with a different type and length to =20= > match the rest of RPL. > OK, done. > The last question in my mind is whether we should also include the =20 > SLLA and MTU options. Make sense to me and got positive answers on =20 > the ML. > That would makes sense. All, please let us know if you disagree by end =20= of the week since we would like to close on this item for the revision 09 that we would like to post before the Virtual WG =20 meeting. Thanks. JP. > Pascal > > >> -----Original Message----- >> From: roll issue tracker [mailto:trac@tools.ietf.org] >> Sent: Thursday, May 27, 2010 11:21 AM >> To: Pascal Thubert (pthubert); jpv@cisco.com >> Cc: roll@ietf.org >> Subject: [roll] #39: RPL option lenght >> >> #39: RPL option lenght >> --------------------------------=20 >> +------------------------------------------- >> Reporter: jpv@=85 | Owner: pthubert@=85 >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------=20 >> +------------------------------------------- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>> Of >>>> Matteo Paris >>>> Sent: Tuesday, May 25, 2010 5:02 PM >>>> To: roll@ietf.org >>>> Subject: [Roll] RPL option length >>>> >>>> >>>> The RPL option length field is 2 bytes long. I propose we change =20= >>>> it >>> to 1 byte. >>>> For comparison, the IPv6 and ND option length fields are >>>> 1 byte long. Since RPL is being designed for constrained devices, >>> there won't >>>> be a need for options bigger than IPv6 and ND options. >>>> >>>> If you agree, please send a quick +1 to the list in reply so we can >>> move this >>>> small matter forward to a ticket. >>>> >>>> Thanks, >>>> Matteo >> >> -- >> Ticket URL: >> roll > From prvs=760676126=mukul@uwm.edu Mon May 31 01:08:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A576C3A6A02 for ; Mon, 31 May 2010 01:08:34 -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 Mkacuwmunwkh for ; Mon, 31 May 2010 01:08:33 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 8EBD93A69F9 for ; Mon, 31 May 2010 01:08:33 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 31 May 2010 03:08:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 8EC372C38015; Mon, 31 May 2010 03:08:21 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC0ReaOZ90uN; Mon, 31 May 2010 03:08:21 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 403312C38011; Mon, 31 May 2010 03:08:21 -0500 (CDT) Date: Mon, 31 May 2010 03:08:21 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <1098473886.15993641275293301163.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1631738713.15993531275293040069.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - SAF3 (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: [Roll] Loose source routing Re: Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 08:08:34 -0000 Hi Jonathan It seems that loose source routing is not possible with proposed type 4 routing header alone. There is no provision to list the ultimate destination of the packet within the proposed header. Would it require a separate header? Could you allow the specification of the ultimate destination as the final entry in the list of addresses or as a separate field? So that it becomes possible to carry a "completely specified piece" of the route in the proposed header. Although RPL base spec does not support loose source routes, we would like to support it in P2P extensions. Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "ROLL WG" Sent: Thursday, May 27, 2010 11:20:31 AM GMT -06:00 US/Canada Central Subject: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 To address RPL ticket #35, we submitted a draft to 6man that proposes a new IPv6 routing header to support source routing in non-storing mode. Some high-level details: - Format is derived from RH0 - Format is extended to support simple compression of IPv6 address entries within the routing header - Use of the RPL routing header is constrained to a RPL domain. http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-00 Comments appreciated as always. -- Jonathan Hui Begin forwarded message: > From: IETF I-D Submission Tool > Date: May 26, 2010 11:41:21 AM PDT > To: jhui@archrock.com > Cc: jpv@cisco.com,culler@cs.berkeley.edu > Subject: New Version Notification for draft-hui-6man-rpl-routing- > header-00 > > > A new version of I-D, draft-hui-6man-rpl-routing-header-00.txt has > been successfully submitted by Jonathan Hui and posted to the IETF > repository. > > Filename: draft-hui-6man-rpl-routing-header > Revision: 00 > Title: A Source Routing Header for RPL > Creation_date: 2010-05-26 > WG ID: Independent Submission > Number_of_pages: 13 > > Abstract: > In Low power and Lossy Networks (LLNs), memory constraints on routers > may limit them to maintaining at most a few routes. In some > configurations, it is necessary to use these memory constrained > routers to deliver datagrams to nodes within the LLN. The Routing > for Low Power and Lossy Networks (RPL) protocol can be used in some > deployments to store most, if not all, routes on one (e.g. the > Directed Acyclic Graph (DAG) root) or few routers and forward the > IPv6 datagram using a source routing technique to avoid large routing > tables on memory constrained routers. This document specifies a new > IPv6 Routing header type for delivering datagrams within a RPL > domain. > > > > The IETF Secretariat. > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=760676126=mukul@uwm.edu Mon May 31 01:23:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D71B3A6A0B for ; Mon, 31 May 2010 01:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Bit8ZbSk7iBA for ; Mon, 31 May 2010 01:23:49 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 3062F3A69FB for ; Mon, 31 May 2010 01:23:49 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 31 May 2010 03:23:25 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id C664A2C38012; Mon, 31 May 2010 03:23:25 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZDL-PoWsLpw; Mon, 31 May 2010 03:23:25 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 61C5B2C3800D; Mon, 31 May 2010 03:23:25 -0500 (CDT) Date: Mon, 31 May 2010 03:23:25 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <437370818.15993951275294205291.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2069499754.15993901275294137703.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - SAF3 (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 08:23:50 -0000 Hi Jonathan >From section 3 in the draft: "When processing the Type 4 Routing header, a router MUST drop the packet if the next entry is not a neighboring node and SHOULD send an ICMP Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set to 7 (to be confirmed by IANA) to the packet's Source Address." I don't think even a storing node would always know if a particular address is not a neighbor. Highly constrained nodes (storing or non-storing) may have very small neighbor table or no neighbor table at all, so they are very likely to not know. I think that the text quoted above should be removed from the draft. Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Yoav Ben-Yehezkel" Cc: "ROLL WG" Sent: Thursday, May 27, 2010 11:56:35 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 On May 27, 2010, at 9:47 AM, Yoav Ben-Yehezkel wrote: > Two small questions/comments about the following text (on page 6) > > else if Address[i] is not an neighboring node { > send an ICMP Destination Unreachable, Code 3, message to > the Source Address and discard the packet > > 1) How does a non-storing device knows Address[i] is not an > neighboring > node? It is non storing... Non-storing means that it doesn't store routes for the destination. A node presumably needs to maintain some notion of neighbors, whether that's through ND or something similar. At the very least, a node could try forwarding the datagram and if it fails then it could indicate that it is not a neighbor. > 2) Code 3 - should be Code 7? Yes, you are right. We originally had Code 3, but through creating a new code would be more appropriate. > also consider changing header from: "RPL Routing Header" to: "Source > Routing Header for RPL" To be completely descriptive, maybe something like "An IPv6 Routing Header for Source Routing with RPL". We are describing a new IPv6 Routing type after all. -- Jonathan Hui > > Best Regards, > Yoav > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Jonathan Hui > Sent: Thursday, May 27, 2010 7:21 PM > To: ROLL WG > Subject: [Roll] Fwd: New Version Notification for > draft-hui-6man-rpl-routing-header-00 > > > To address RPL ticket #35, we submitted a draft to 6man that proposes > a new IPv6 routing header to support source routing in non-storing > mode. > > Some high-level details: > - Format is derived from RH0 > - Format is extended to support simple compression of IPv6 address > entries within the routing header > - Use of the RPL routing header is constrained to a RPL domain. > > http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-00 > > Comments appreciated as always. > > -- > Jonathan Hui > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: May 26, 2010 11:41:21 AM PDT >> To: jhui@archrock.com >> Cc: jpv@cisco.com,culler@cs.berkeley.edu >> Subject: New Version Notification for draft-hui-6man-rpl-routing- >> header-00 >> >> >> A new version of I-D, draft-hui-6man-rpl-routing-header-00.txt has >> been successfully submitted by Jonathan Hui and posted to the IETF >> repository. >> >> Filename: draft-hui-6man-rpl-routing-header >> Revision: 00 >> Title: A Source Routing Header for RPL >> Creation_date: 2010-05-26 >> WG ID: Independent Submission >> Number_of_pages: 13 >> >> Abstract: >> In Low power and Lossy Networks (LLNs), memory constraints on routers >> may limit them to maintaining at most a few routes. In some >> configurations, it is necessary to use these memory constrained >> routers to deliver datagrams to nodes within the LLN. The Routing >> for Low Power and Lossy Networks (RPL) protocol can be used in some >> deployments to store most, if not all, routes on one (e.g. the >> Directed Acyclic Graph (DAG) root) or few routers and forward the >> IPv6 datagram using a source routing technique to avoid large routing >> tables on memory constrained routers. This document specifies a new >> IPv6 Routing header type for delivering datagrams within a RPL >> domain. >> >> >> >> The IETF Secretariat. >> >> > > _______________________________________________ > 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 jpv@cisco.com Mon May 31 03:10:04 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6713A6A27 for ; Mon, 31 May 2010 03:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 dJuOQKJOpamk for ; Mon, 31 May 2010 03:10:02 -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 C49E63A67C2 for ; Mon, 31 May 2010 03:10:01 -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: AvsEABMoA0xAZnwM/2dsb2JhbACeM3GnEJlChRYEj2E X-IronPort-AV: E=Sophos;i="4.53,332,1272844800"; d="scan'208";a="116351996" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 31 May 2010 10:09:49 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4VA9mKb016704; Mon, 31 May 2010 10:09:49 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 12:09:48 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 12:09:47 +0200 Message-Id: <97969728-76B2-4E1D-94F7-067753376BCF@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <1098473886.15993641275293301163.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 31 May 2010 12:09:46 +0200 References: <1098473886.15993641275293301163.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 31 May 2010 10:09:48.0167 (UTC) FILETIME=[66A3B970:01CB00A9] Cc: ROLL WG Subject: Re: [Roll] Loose source routing Re: Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 10:10:04 -0000 Hi Mukul, On May 31, 2010, at 10:08 AM, Mukul Goyal wrote: > Hi Jonathan > > It seems that loose source routing is not possible with proposed > type 4 routing header alone. > > There is no provision to list the ultimate destination of the packet > within the proposed header. > > Would it require a separate header? > > Could you allow the specification of the ultimate destination as the > final entry in the list of addresses or as a separate field? So that > it becomes possible to carry a "completely specified piece" of the > route in the proposed header. > > Although RPL base spec does not support loose source routes, we > would like to support it in P2P extensions. > It is workable but let's bear in mind that loose routing add a significant level of complexity (since this is something that Jonathan, David and discussed). Is this really a requirement for your P2P solution ? Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "Jonathan Hui" > To: "ROLL WG" > Sent: Thursday, May 27, 2010 11:20:31 AM GMT -06:00 US/Canada Central > Subject: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl- > routing-header-00 > > > To address RPL ticket #35, we submitted a draft to 6man that proposes > a new IPv6 routing header to support source routing in non-storing > mode. > > Some high-level details: > - Format is derived from RH0 > - Format is extended to support simple compression of IPv6 address > entries within the routing header > - Use of the RPL routing header is constrained to a RPL domain. > > http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-00 > > Comments appreciated as always. > > -- > Jonathan Hui > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: May 26, 2010 11:41:21 AM PDT >> To: jhui@archrock.com >> Cc: jpv@cisco.com,culler@cs.berkeley.edu >> Subject: New Version Notification for draft-hui-6man-rpl-routing- >> header-00 >> >> >> A new version of I-D, draft-hui-6man-rpl-routing-header-00.txt has >> been successfully submitted by Jonathan Hui and posted to the IETF >> repository. >> >> Filename: draft-hui-6man-rpl-routing-header >> Revision: 00 >> Title: A Source Routing Header for RPL >> Creation_date: 2010-05-26 >> WG ID: Independent Submission >> Number_of_pages: 13 >> >> Abstract: >> In Low power and Lossy Networks (LLNs), memory constraints on routers >> may limit them to maintaining at most a few routes. In some >> configurations, it is necessary to use these memory constrained >> routers to deliver datagrams to nodes within the LLN. The Routing >> for Low Power and Lossy Networks (RPL) protocol can be used in some >> deployments to store most, if not all, routes on one (e.g. the >> Directed Acyclic Graph (DAG) root) or few routers and forward the >> IPv6 datagram using a source routing technique to avoid large routing >> tables on memory constrained routers. This document specifies a new >> IPv6 Routing header type for delivering datagrams within a RPL >> domain. >> >> >> >> The IETF Secretariat. >> >> > > _______________________________________________ > 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 Mon May 31 04:42:20 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3263A67DA for ; Mon, 31 May 2010 04:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 gMf+XuDjJDt4 for ; Mon, 31 May 2010 04:42:18 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 479F63A6816 for ; Mon, 31 May 2010 04:42:18 -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, 31 May 2010 13:42:05 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A1BF@zensys17.zensys.local> In-Reply-To: <437370818.15993951275294205291.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notification fordraft-hui-6man-rpl-routing-header-00 thread-index: AcsAmpYvfjbGpQhARw+hWsYGYg5l1QAGu6Ig References: <2069499754.15993901275294137703.JavaMail.root@mail02.pantherlink.uwm.edu> <437370818.15993951275294205291.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Anders Brandt" To: "Mukul Goyal" , "Jonathan Hui" Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification fordraft-hui-6man-rpl-routing-header-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 11:42:20 -0000 Mukul, Jonahan, I agree on this one: > I don't think even a storing node would always know if a=20 > particular address is not a neighbor. Highly constrained=20 > nodes (storing or non-storing) may have very small neighbor=20 > table or no neighbor table at all, so they are very likely to=20 > not know. It is unlikely that most constrained nodes will have storage for this. Therefore this may be the most sensible thing to do: > At the very least, a node could try forwarding the datagram=20 > and if it fails then it could indicate that it is not a neighbor. In essence, reverse the routing stack pointer direction and send a NUD back to the source (possibly after a number of retries). - Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Mukul Goyal > Sent: Monday, May 31, 2010 10:23 > To: Jonathan Hui > Cc: ROLL WG > Subject: Re: [Roll] Fwd: New Version Notification=20 > fordraft-hui-6man-rpl-routing-header-00 >=20 > Hi Jonathan >=20 > From section 3 in the draft: > "When > processing the Type 4 Routing header, a router MUST drop the packet > if the next entry is not a neighboring node and SHOULD send an ICMP > Destination Unreachable (ICMPv6 Type 1) message with=20 > ICMPv6 Code set > to 7 (to be confirmed by IANA) to the packet's Source Address." >=20 > I don't think even a storing node would always know if a=20 > particular address is not a neighbor. Highly constrained=20 > nodes (storing or non-storing) may have very small neighbor=20 > table or no neighbor table at all, so they are very likely to=20 > not know. I think that the text quoted above should be=20 > removed from the draft.=20 >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Jonathan Hui" > To: "Yoav Ben-Yehezkel" > Cc: "ROLL WG" > Sent: Thursday, May 27, 2010 11:56:35 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Fwd: New Version Notification for=20 > draft-hui-6man-rpl-routing-header-00 >=20 >=20 > On May 27, 2010, at 9:47 AM, Yoav Ben-Yehezkel wrote: >=20 > > Two small questions/comments about the following text (on page 6) > > > > else if Address[i] is not an neighboring node { > > send an ICMP Destination Unreachable, Code 3,=20 > message to > > the Source Address and discard the packet > > > > 1) How does a non-storing device knows Address[i] is not an=20 > > neighboring node? It is non storing... >=20 > Non-storing means that it doesn't store routes for the=20 > destination. A node presumably needs to maintain some notion=20 > of neighbors, whether that's through ND or something similar.=20 > At the very least, a node could try forwarding the datagram=20 > and if it fails then it could indicate that it is not a neighbor. >=20 > > 2) Code 3 - should be Code 7? >=20 > Yes, you are right. We originally had Code 3, but through=20 > creating a new code would be more appropriate. >=20 > > also consider changing header from: "RPL Routing Header"=20 > to: "Source=20 > > Routing Header for RPL" >=20 > To be completely descriptive, maybe something like "An IPv6=20 > Routing Header for Source Routing with RPL". We are=20 > describing a new IPv6 Routing type after all. >=20 > -- > Jonathan Hui >=20 > > > > Best Regards, > > Yoav > > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]=20 > On Behalf=20 > > Of Jonathan Hui > > Sent: Thursday, May 27, 2010 7:21 PM > > To: ROLL WG > > Subject: [Roll] Fwd: New Version Notification for=20 > > draft-hui-6man-rpl-routing-header-00 > > > > > > To address RPL ticket #35, we submitted a draft to 6man=20 > that proposes > > a new IPv6 routing header to support source routing in non-storing =20 > > mode. > > > > Some high-level details: > > - Format is derived from RH0 > > - Format is extended to support simple compression of IPv6 address > > entries within the routing header > > - Use of the RPL routing header is constrained to a RPL domain. > > > > http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-00 > > > > Comments appreciated as always. > > > > -- > > Jonathan Hui > > > > Begin forwarded message: > > > >> From: IETF I-D Submission Tool > >> Date: May 26, 2010 11:41:21 AM PDT > >> To: jhui@archrock.com > >> Cc: jpv@cisco.com,culler@cs.berkeley.edu > >> Subject: New Version Notification for draft-hui-6man-rpl-routing- > >> header-00 > >> > >> > >> A new version of I-D, draft-hui-6man-rpl-routing-header-00.txt has > >> been successfully submitted by Jonathan Hui and posted to the IETF > >> repository. > >> > >> Filename: draft-hui-6man-rpl-routing-header > >> Revision: 00 > >> Title: A Source Routing Header for RPL > >> Creation_date: 2010-05-26 > >> WG ID: Independent Submission > >> Number_of_pages: 13 > >> > >> Abstract: > >> In Low power and Lossy Networks (LLNs), memory constraints=20 > on routers > >> may limit them to maintaining at most a few routes. In some > >> configurations, it is necessary to use these memory constrained > >> routers to deliver datagrams to nodes within the LLN. The Routing > >> for Low Power and Lossy Networks (RPL) protocol can be used in some > >> deployments to store most, if not all, routes on one (e.g. the > >> Directed Acyclic Graph (DAG) root) or few routers and forward the > >> IPv6 datagram using a source routing technique to avoid=20 > large routing > >> tables on memory constrained routers. This document=20 > specifies a new > >> IPv6 Routing header type for delivering datagrams within a RPL > >> domain. > >> > >> > >> > >> The IETF Secretariat. > >> > >> > > > > _______________________________________________ > > 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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From pal@cs.stanford.edu Mon May 31 13:45:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA043A6873 for ; Mon, 31 May 2010 13:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[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 GQbXtst1kt+u for ; Mon, 31 May 2010 13:45:17 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id B85E13A67F5 for ; Mon, 31 May 2010 13:45:17 -0700 (PDT) Received: from dnab404624.stanford.edu ([171.64.70.36]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OJBr8-0006uZ-1J; Mon, 31 May 2010 13:45:06 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <437370818.15993951275294205291.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Mon, 31 May 2010 13:45:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <234ED0F2-1CAD-49EB-A4B7-E5EFCFC669F5@cs.stanford.edu> References: <437370818.15993951275294205291.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1078) X-Scan-Signature: 980022258218d8e0da9e8fd80fb6777b Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 20:45:18 -0000 On May 31, 2010, at 1:23 AM, Mukul Goyal wrote: > Hi Jonathan >=20 > =46rom section 3 in the draft: > "When > processing the Type 4 Routing header, a router MUST drop the packet > if the next entry is not a neighboring node and SHOULD send an ICMP > Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set > to 7 (to be confirmed by IANA) to the packet's Source Address." >=20 > I don't think even a storing node would always know if a particular = address is not a neighbor. Highly constrained nodes (storing or = non-storing) may have very small neighbor table or no neighbor table at = all, so they are very likely to not know. I think that the text quoted = above should be removed from the draft.=20 I'll return to my comment on this line of argument -- it seems to be = introducing a new requirement which doesn't exist in any of the = requirement documents: a node must be able to route without a neighbor = table. If this is truly a requirement, rather than a convincing argument = for a particular approach, then we need to re-examine the requirements = documents and several parts of RPL. Do we? Phil= From trac@tools.ietf.org Mon May 31 14:17:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC543A682D for ; Mon, 31 May 2010 14:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.039 X-Spam-Level: X-Spam-Status: No, score=-102.039 tagged_above=-999 required=5 tests=[AWL=0.561, 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 VvAVaiQtCUnC for ; Mon, 31 May 2010 14:17:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 88A553A689A for ; Mon, 31 May 2010 14:17:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OJCLy-0001yB-OJ; Mon, 31 May 2010 14:16:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Mon, 31 May 2010 21:16:58 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/30#comment:2 Message-ID: <064.56c3cca6ac5e82243650bb635c1a89bd@tools.ietf.org> References: <055.d2eab2c729c6835d4457709ee6cb8117@tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <055.d2eab2c729c6835d4457709ee6cb8117@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@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: roll@ietf.org Subject: Re: [Roll] [roll] #30: Clearly documenting Multicast mode of operation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 21:17:13 -0000 #30: Clearly documenting Multicast mode of operation --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: task | Status: reopened Priority: minor | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: closed => reopened * resolution: fixed => Comment: Closed too soon ... requires more text. -- Ticket URL: roll From wintert@acm.org Mon May 31 15:53:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 380A83A690D for ; Mon, 31 May 2010 15:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=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 MkRZy3-701tx for ; Mon, 31 May 2010 15:53:53 -0700 (PDT) Received: from smtp108.prem.mail.ac4.yahoo.com (smtp108.prem.mail.ac4.yahoo.com [76.13.13.47]) by core3.amsl.com (Postfix) with SMTP id EF2973A6A1C for ; Mon, 31 May 2010 15:53:52 -0700 (PDT) Received: (qmail 59439 invoked from network); 31 May 2010 22:53:38 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp108.prem.mail.ac4.yahoo.com with SMTP; 31 May 2010 15:53:37 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: vNClb2EVM1ni28pJ2oe51hWqonSaAb5T972g57t75QYC_IDXU2Lrwng88tuEwy847WnFZDPFrXZfyFZvK82HzTFRe4CwX1x84SAefJLoGBn6ttGGoebnV2uH8wL4af92tG_CyjeRvejhtW_0dr3efIfGOqAOXfpxA9ahqt8tHEYD6BBrIJtRa1VU1DrPUGewbkjsheVhyA4UazIoapj2DxZC7PcEDADSfcarPHaNCoYJkgKbyc2TigtpMOHOTvv_j0tKUN1qPB4DqhMCSmQguJo.iyobDVDGFrRvTFqRCGxLwR069qH_pU39 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C043DF1.9020506@acm.org> Date: Mon, 31 May 2010 18:53:37 -0400 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: ROLL WG References: <20100528214502.CA5A63A67B1@core3.amsl.com> In-Reply-To: <20100528214502.CA5A63A67B1@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-08.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 22:53:54 -0000 WG, In this version we have addressed a number of open tickets and feedback. The changes include: - Updated RPL Options to 8-bit length - Incorporated security inputs as provided by Security Design Team, still a work-in-progress to be completed by upcoming -09 - Updated terminology from {Iteration, DODAGSequenceNumber} to {Version, DODAGVersionNumber} - Updated text to reference I-D.ietf-roll-trickle for trickle specification - Added reference to I-D.hui-6man-rpl-option to carry packet meta-data, I-D.hui-6man-rpl-routing-header for source routing - Defined Global/Local RPLInstanceID, where Local RPLInstanceID is in support of P2P solution - Added Mode of Operation (MOP) to specify that the instance is in Storing or Non-storing node. Removed 'S' bit and description of mixed-mode operation (MOP may be expanded later) - Added Path Control to indicate preference and limit fan-out for DAO operation. (Needs additional clarification for non-storing mode). Removed DAO Rank. - Added DAO-ACK - Added Route Information Option (RIO) and Prefix Information Option (PIO), borrowed from IPv6 ND (removed obsolete Destination Prefix Option) - Added Target and Transit Information options, which may be thought of as an expanded and more flexible version of the previous DAO body. This will also allow for Target to be reused in P2P solution - No-DAO -> No-Path (There is a DAO, just not a path) Please do continue to send your comments and feedback to the list. Thanks, -RPL Author Team On 05/28/2010 05:45 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-08.txt > Pages : 92 > Date : 2010-05-28 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained: LLN routers > typically operate with constraints on (any subset of) processing > power, memory and energy (battery), and their interconnects are > characterized by (any subset of) high loss rates, low data rates and > instability. LLNs are comprised of anything from a few dozen and up > to thousands of routers, and support point-to-point traffic (between > devices inside the LLN), point-to-multipoint traffic (from a central > control point to a subset of devices inside the LLN) and multipoint- > to-point traffic (from devices inside the LLN towards a central > control point). This document specifies the IPv6 Routing Protocol > for LLNs (RPL), which provides a mechanism whereby multipoint-to- > point traffic from devices inside the LLN towards a central control > point, as well as point-to-multipoint traffic from the central > control point to the devices inside the LLN, is supported. Support > for point-to-point traffic is also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From dat@exegin.com Mon May 31 16:04:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DE683A6782 for ; Mon, 31 May 2010 16:04:41 -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 ZsGyRT30r2Sm for ; Mon, 31 May 2010 16:04:40 -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 F1E063A672E for ; Mon, 31 May 2010 16:04:39 -0700 (PDT) Received: by pvh11 with SMTP id 11so532664pvh.31 for ; Mon, 31 May 2010 16:04:25 -0700 (PDT) Received: by 10.141.53.3 with SMTP id f3mr3790400rvk.195.1275347063360; Mon, 31 May 2010 16:04:23 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id b2sm4655714rvn.19.2010.05.31.16.04.22 (version=SSLv3 cipher=RC4-MD5); Mon, 31 May 2010 16:04:22 -0700 (PDT) Message-ID: <4C044071.9060805@exegin.com> Date: Mon, 31 May 2010 16:04:17 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: roll@ietf.org References: <20100528214502.CA5A63A67B1@core3.amsl.com> In-Reply-To: <20100528214502.CA5A63A67B1@core3.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] draft-rpl-08: Target and OCP sub-options share code 5 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 23:04:41 -0000 Seems that the new "RPL Target" sub-option uses the same type-value (5) as the OCP sub-option that is defined in "draft-ietf-roll-routing-metrics-06" (section 6). Dario Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-08.txt > Pages : 92 > Date : 2010-05-28 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained: LLN routers > typically operate with constraints on (any subset of) processing > power, memory and energy (battery), and their interconnects are > characterized by (any subset of) high loss rates, low data rates and > instability. LLNs are comprised of anything from a few dozen and up > to thousands of routers, and support point-to-point traffic (between > devices inside the LLN), point-to-multipoint traffic (from a central > control point to a subset of devices inside the LLN) and multipoint- > to-point traffic (from devices inside the LLN towards a central > control point). This document specifies the IPv6 Routing Protocol > for LLNs (RPL), which provides a mechanism whereby multipoint-to- > point traffic from devices inside the LLN towards a central control > point, as well as point-to-multipoint traffic from the central > control point to the devices inside the LLN, is supported. Support > for point-to-point traffic is also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From prvs=761c94e41=mukul@uwm.edu Mon May 31 20:37:27 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C67EB3A68DE for ; Mon, 31 May 2010 20:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.279, 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 j3qbSy4UCiDn for ; Mon, 31 May 2010 20:37:26 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id B1DA63A6819 for ; Mon, 31 May 2010 20:37:26 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 31 May 2010 22:37:14 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 731D72C3800E; Mon, 31 May 2010 22:37:14 -0500 (CDT) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2Om5AEEIRjG; Mon, 31 May 2010 22:37:14 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 4916D2C3800D; Mon, 31 May 2010 22:37:14 -0500 (CDT) Date: Mon, 31 May 2010 22:37:14 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1357470253.16092481275363434212.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2028555274.16092251275363253886.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - SAF3 (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 03:37:27 -0000 Hi Philip In this particular case, the intent is to require that a router MUST drop a packet if it can not deliver the packet to the next entry in the routing header in one IP hop. I think the authors will update the language to this effect. In general and in context of P2P mechanisms, the requirement is to allow operation with highly constrained (in memory) devices. The neighbor table, in general, will contain only a subset of neighbors. There is no reason to not use neighbors not in neighbor table if the underlying routing metrics do not require maintenance of neighbor-specific state. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "Mukul Goyal" Cc: "Jonathan Hui" , "ROLL WG" Sent: Monday, May 31, 2010 3:45:05 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00 On May 31, 2010, at 1:23 AM, Mukul Goyal wrote: > Hi Jonathan > > From section 3 in the draft: > "When > processing the Type 4 Routing header, a router MUST drop the packet > if the next entry is not a neighboring node and SHOULD send an ICMP > Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set > to 7 (to be confirmed by IANA) to the packet's Source Address." > > I don't think even a storing node would always know if a particular address is not a neighbor. Highly constrained nodes (storing or non-storing) may have very small neighbor table or no neighbor table at all, so they are very likely to not know. I think that the text quoted above should be removed from the draft. I'll return to my comment on this line of argument -- it seems to be introducing a new requirement which doesn't exist in any of the requirement documents: a node must be able to route without a neighbor table. If this is truly a requirement, rather than a convincing argument for a particular approach, then we need to re-examine the requirements documents and several parts of RPL. Do we? Phil From abr@sdesigns.dk Mon May 31 23:55:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870E728C14E for ; Mon, 31 May 2010 23:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=-0.696, 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 OW6vsqOF6Aee for ; Mon, 31 May 2010 23:55:46 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 52A6028C149 for ; Mon, 31 May 2010 23:55:46 -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: Tue, 1 Jun 2010 08:55:33 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A1CB@zensys17.zensys.local> In-Reply-To: <1357470253.16092481275363434212.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notification fordraft-hui-6man-rpl-routing-header-00 thread-index: AcsBO76mQ/9MVjjFQ7yhdGCdcKvEHwAGc4VQ References: <2028555274.16092251275363253886.JavaMail.root@mail02.pantherlink.uwm.edu> <1357470253.16092481275363434212.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Anders Brandt" To: "Mukul Goyal" , "Philip Levis" Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification fordraft-hui-6man-rpl-routing-header-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 06:55:47 -0000 Hi Phil=20 Comment inline. Cheers, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Mukul Goyal > Sent: Tuesday, June 01, 2010 05:37 > To: Philip Levis > Cc: ROLL WG > Subject: Re: [Roll] Fwd: New Version Notification=20 > fordraft-hui-6man-rpl-routing-header-00 >=20 > Hi Philip >=20 > In this particular case, the intent is to require that a=20 > router MUST drop a packet if it can not deliver the packet to=20 > the next entry in the routing header in one IP hop. I think=20 > the authors will update the language to this effect. >=20 > In general and in context of P2P mechanisms, the requirement=20 > is to allow operation with highly constrained (in memory)=20 > devices. The neighbor table, in general, will contain only a=20 > subset of neighbors. There is no reason to not use neighbors=20 > not in neighbor table if the underlying routing metrics do=20 > not require maintenance of neighbor-specific state. >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Philip Levis" > To: "Mukul Goyal" > Cc: "Jonathan Hui" , "ROLL WG" > Sent: Monday, May 31, 2010 3:45:05 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Fwd: New Version Notification for=20 > draft-hui-6man-rpl-routing-header-00 >=20 >=20 > On May 31, 2010, at 1:23 AM, Mukul Goyal wrote: >=20 > > Hi Jonathan > >=20 > > From section 3 in the draft: > > "When > > processing the Type 4 Routing header, a router MUST drop=20 > the packet > > if the next entry is not a neighboring node and SHOULD=20 > send an ICMP > > Destination Unreachable (ICMPv6 Type 1) message with=20 > ICMPv6 Code set > > to 7 (to be confirmed by IANA) to the packet's Source Address." > >=20 > > I don't think even a storing node would always know if a=20 > particular address is not a neighbor. Highly constrained=20 > nodes (storing or non-storing) may have very small neighbor=20 > table or no neighbor table at all, so they are very likely to=20 > not know. I think that the text quoted above should be=20 > removed from the draft.=20 >=20 > I'll return to my comment on this line of argument -- it=20 > seems to be introducing a new requirement which doesn't exist=20 > in any of the requirement documents: a node must be able to=20 > route without a neighbor table. If this is truly a=20 Agreed. The home requirements spec does not explicitly say that a node MUST operate without a neighbor table. I would claim that this somewhat has to do with scoping of our individual mindsets. Over time I have found that Kris and Pascal has a different interpretation of "memory constrained" than Jerry and me. I want to support Mukul that at best, a home (or building) node may hold link information on a few neighbors out of potentially 100's in a dense network. There is a reason we prefer source routing in this environment. > requirement, rather than a convincing argument for a=20 > particular approach, then we need to re-examine the=20 > requirements documents and several parts of RPL. Do we? >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20
Does that make sense = ?