From pthubert@cisco.com Mon Jan 3 06:44:40 2011 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 BD3AB28C12D for ; Mon, 3 Jan 2011 06:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.021 X-Spam-Level: X-Spam-Status: No, score=-10.021 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, J_CHICKENPOX_33=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 k3fHURRovONQ for ; Mon, 3 Jan 2011 06:44:39 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 9996828C12C for ; Mon, 3 Jan 2011 06:44:38 -0800 (PST) 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: AvYEAD1wIU2Q/khNgWdsb2JhbACkNBUBARYiJKJPmEyFSgSOJw X-IronPort-AV: E=Sophos;i="4.60,267,1291593600"; d="scan'208";a="16210474" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 03 Jan 2011 14:46:45 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p03EkjRK002969; Mon, 3 Jan 2011 14:46: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.4675); Mon, 3 Jan 2011 15:46:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Jan 2011 15:46:44 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0385ED21@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcueyoLKJOy0wc4FT5Kc5nBhyylQqwEmOeAQAB+DoZoB2Jl6AA== References: <6A2A459175DABE4BB11DE2026AA50A5D037A7283@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Skip Ashton" , "Don Sturek" , "Yoav Ben-Yehezkel" X-OriginalArrivalTime: 03 Jan 2011 14:46:44.0722 (UTC) FILETIME=[0A848D20:01CBAB55] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.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, 03 Jan 2011 14:44:41 -0000 Hi Skip "this" is a bit vague. This discussion was about 1 DAG vs. 2 DAGs vs. n DAGs. My argument is that 1 DAG for asymmetrical links will be more complex and less efficient than 2, whereas n DAGs address a different problem where all n nodes are destinations for traffic from the other nodes. WRTthe problem of the first hop link metric that you raise here, we enter another discussion which is not dependent on how many DAGs we decide to build. In a general manner, a DIO indicates what its sender sees and does not depend on the receiver. Thus, the specific information about the link to the receiver is not present in the L3 information. Yes, we discussed that as well, and yes, we need information about the link that had to be obtained by some link specific method. What I gather from this discussion is that: 1) the metrics draft could have a field indicating if a given metric is up, down or bidirectional 2) the metrics draft could have words about the first hop link metrics, what can be expected from RPL and what is needed from more L2 triggers. Happy New Year! Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Skip Ashton [mailto:skip.ashton@ember.com] > Sent: Saturday, December 25, 2010 4:12 AM > To: Pascal Thubert (pthubert); Don Sturek; Yoav Ben-Yehezkel > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >=20 > We have discussed this before and it does not work properly. The DAG > represents the metric back to the root and in this case we need to know the > link quality between two adjacent devices. Knowing the aggregate cost to > the root does not give you enough information on if this link is suitable. >=20 > Skip >=20 >=20 > On 12/24/10 7:14 AM, "Pascal Thubert (pthubert)" > wrote: >=20 > > Hi Don: > > > > My proposal is 2 set up 2 DAGS, one DIO only for upward traffic, and > > one > > DIO+DAO for downward traffic. > > The first DAG would be established using metrics that describe the > > upward direction of the link, while the other would be established > > with downwards metrics. > > The resulting topology is roughly equivalent to having a single DAG > > with an OF that could read metrics for both directions. In any case, > > you end up with 2 sets of parents. > > > > From your response, it is quite probable that you misunderstood that > > proposal, and quite probable that you interpreted my words as a DAG > > per destination. > > If so, please reconsider... > > > > Merry Xmas yall! > > > > Pascal > > http://www.xtranormal.com/watch/7011357/ > > > > > >> -----Original Message----- > >> From: Don Sturek [mailto:d.sturek@att.net] > >> Sent: Saturday, December 18, 2010 4:47 PM > >> To: Yoav Ben-Yehezkel > >> Cc: Pascal Thubert (pthubert); ROLL WG > >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > >> > >> Hi yoav, > >> > >> True, however then you need some OF to handle asymmetric links. I > > think > >> pascal proposes separate DAGs to handle that. > >> > >> Don > >> > >> Sent from my iPad > >> > >> On Dec 18, 2010, at 6:25 AM, Yoav Ben-Yehezkel > > wrote: > >> > >>> My understanding WRT a solution to the asymmetric links was that > > that > >>> RPL can settle with just one DAG by use of DAO messages that allows > > a > >>> bi-directional downwards route creation. > >>> > >>> Can that be considered a legit solution to asymmetric links a well? > >>> > >>> Regards, > >>> Yoav > >>> > >>> > >>> -----Original Message----- > >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > >>> Of Don Sturek > >>> Sent: Saturday, December 18, 2010 4:19 PM > >>> To: Pascal Thubert (pthubert) > >>> Cc: ROLL WG > >>> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > >>> > >>> Hi pascal, > >>> > >>> What you wrote below in the last paragraph is wrong. In fact, it is > >>> not 2 Dags that must be created but an order n number of Dags to > > cover > >>> any of the return paths to any of the nodes which could have > > generated a > >> request. > >>> > >>> Don > >>> > >>> > >>> Sent from my iPad > >>> > >>> On Dec 18, 2010, at 4:38 AM, "Pascal Thubert (pthubert)" > >>> wrote: > >>> > >>>> Again you've got your logic reversed. RPL was designed for LLNs, > > does > >>>> not mean that it has to be limited to anything as long as it works > >>>> fine there too. > >>>> > >>>> Second you'll find more and more low power / constrained devices > > in > >>>> both wired and wireless space, because as a trend we are > > controlling > >>>> more and wasting less. > >>>> > >>>> Third, RPL by construction is a good routing protocol for certain > >>>> topologies that are inherently based on hub and spoke. I listed a > >>>> number in this thread already. Think dynamic overlays like VPNs > > for one. > >>>> > >>>> Finally, OF0 may apply to asymmetric links if people are willing to > >>>> run > >>>> 2 DAGs, one for the traffic up and one for the traffic down. Mixing > >>>> problems is a source of confusion. > >>>> > >>>> Pascal > >>>> http://www.xtranormal.com/watch/7011357/ > >>>> > >>>>> -----Original Message----- > >>>>> From: Philip Levis [mailto:pal@cs.stanford.edu] > >>>>> Sent: Friday, December 17, 2010 10:32 PM > >>>>> To: Pascal Thubert (pthubert) > >>>>> Cc: Don Sturek; ROLL WG > >>>>> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > >>>>> > >>>>> > >>>>> On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: > >>>>> > >>>>>> Don: > >>>>>> > >>>>>> I listed a number of examples and none of them is PLC actually. > >>>>>> RPL is a routing protocol. There is no point in preventing its > >>>>>> usage > >>>> on wired > >>>>> lines. > >>>>>> > >>>>> > >>>>> https://datatracker.ietf.org/wg/roll/charter/: > >>>>> > >>>>> The Working Group is focused on routing issues for LLN. > >>>>> > >>>>> Can you give me an example of a wired network that's an LLN where > >>>>> OF0 > >>>> is > >>>>> useful? > >>>>> > >>>>> 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 Jorjeta.Jetcheva@itron.com Mon Jan 3 11:11:30 2011 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 A4FD53A6AED for ; Mon, 3 Jan 2011 11:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 zfTdfeh0iWtV for ; Mon, 3 Jan 2011 11:11:27 -0800 (PST) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by core3.amsl.com (Postfix) with ESMTP id 35D9E3A6AEA for ; Mon, 3 Jan 2011 11:11:26 -0800 (PST) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.112]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Mon, 3 Jan 2011 11:13:33 -0800 From: "Jetcheva, Jorjeta" To: "roll@ietf.org" Date: Mon, 3 Jan 2011 11:13:35 -0800 Thread-Topic: question about broken link detection Thread-Index: AcurelGPfOoVdv2LTtCiRV+fh7U09A== Message-ID: <0368F388C03BB34BBBFA73209849D47A063CC3A8@ITR-EXMBXVS-2.itron.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_0368F388C03BB34BBBFA73209849D47A063CC3A8ITREXMBXVS2itro_" MIME-Version: 1.0 Subject: [Roll] question about broken link detection 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 Jan 2011 19:11:30 -0000 --_000_0368F388C03BB34BBBFA73209849D47A063CC3A8ITREXMBXVS2itro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, Happy New Year! I am trying to understand how RPL deals with broken links in non-storing mo= de so I wanted to run several scenarios by the group. When a packet is tra= nsmitted downstream and reaches a broken link, e.g., from node A to node B,= and the transmitting node (node A) doesn't get a link layer ack from the = downstream next hop (node B) after sending several retransmissions, it can = send an ICMP destination unreachable packet to the root. The root can then= try to use other routes it has to the destination or if it doesn't know of= any other ones, it can: 1. Increment its DTSN, triggering all nodes in the DODAG to send it = a DAO, at which point the downstream node adjacent to the broken link (node= B) will detect that the link to its parent (node A) is broken and will sel= ect a new preferred parent (assuming it has other possible parents) and sen= d a DAO. 2. Wait for the downstream node in the broken link (node B) to detect= that its parent (node A) is not reachable A. When the downstream node (Node B) observes that it hasn't gotten a = DIO from its parent (node A) for a while, and it would select a new preferr= ed parent (assuming it has other possible parents) and send a DAO to the ro= ot B. If traffic happens to be flowing upstream, the lack of per-hop/link= layer acks would indicate the upstream parent (node A) is no longer reacha= ble and a new parent will be selected, and a DAO would be sent to the root. Are these the options for detecting a broken link when forwarding a packet = downstream in non-storing mode? Is there a preferred mechanism for this? Thanks! Jorjeta --_000_0368F388C03BB34BBBFA73209849D47A063CC3A8ITREXMBXVS2itro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

Happy New Year!

 

I am trying to understand how RPL deals with broken li= nks in non-storing mode so I wanted to run several scenarios by the group.  W= hen a packet is transmitted downstream and reaches a broken link, e.g., from no= de A to node B,  and the transmitting node (node A) doesn’t get a lin= k layer ack from the downstream next hop (node B) after sending several retransmissions, it can send an ICMP destination unreachable packet to the root.  The root can then try to use other routes it has to the destina= tion or if it doesn’t know of any other ones, it can:

 

1.      =  Increment its DTSN, triggering all nodes in the DODAG to send it a DAO, at which poin= t the downstream node adjacent to the broken link (node B) will detect that t= he link to its parent (node A) is broken and will select a new preferred paren= t (assuming it has other possible parents) and send a DAO.

2.      = Wait for the downstream node in the broken link (node B) to detect that its pare= nt (node A) is not reachable

A.      When the downstream node (Node B) observes that it hasn’t gotten a DIO fro= m its parent (node A) for a while, and it would select a new preferred parent (as= suming it has other possible parents) and send a DAO to the root

B.      If traffic happens to be flowing upstream, the lack of per-hop/link layer acks= would indicate the upstream parent (node A) is no longer reachable and a new pare= nt will be selected, and a DAO would be sent to the root.

Are these the options for detecting a broken link when forwarding a packet downstream in non-storing mode?  Is there a prefer= red mechanism for this?

 

Thanks!

 

Jorjeta

--_000_0368F388C03BB34BBBFA73209849D47A063CC3A8ITREXMBXVS2itro_-- From jreddy@ti.com Mon Jan 3 16:08:41 2011 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 7BEE23A6E22 for ; Mon, 3 Jan 2011 16:08:41 -0800 (PST) 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 x9w0iWIea1NR for ; Mon, 3 Jan 2011 16:08:40 -0800 (PST) Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by core3.amsl.com (Postfix) with ESMTP id 772733A6E21 for ; Mon, 3 Jan 2011 16:08:40 -0800 (PST) Received: from dlep33.itg.ti.com ([157.170.170.112]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id p040AkDE001036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Jan 2011 18:10:46 -0600 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 p040AkRj021809 for ; Mon, 3 Jan 2011 18:10:46 -0600 (CST) 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 p040Akiw019033 for ; Mon, 3 Jan 2011 18:10:46 -0600 (CST) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee74.ent.ti.com ([157.170.170.8]) with mapi; Mon, 3 Jan 2011 18:10:46 -0600 From: "Reddy, Joseph" To: "roll@ietf.org" Date: Mon, 3 Jan 2011 18:10:44 -0600 Thread-Topic: question about broken link detection Thread-Index: AcurgTVJ2A0Msg5/SRqfG6y1HLXhvQAFXhHw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] question about broken link detection 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 Jan 2011 00:08:41 -0000 =20 Hi Jorjeta, Option 1 will work but at the expense of lot of ( unnecessary ) traffic Option 2 has less overhead but may not work in all networks.=20 The DIO transmissions can be very rare in a static network, so lack of DIO'= s may not be a practical method to detect broken downward paths.=20 If there is upsteam traffic and missing ack's , that is certainly reason to= update the DAO parent set and send updated info to the root. But, of cours= e, this cannot be guaranteed in all networks. The reliable detection of broken downward paths can only be done by the ups= tream node. So it would be nice if there was a way for an upstream node to = initiate route repair for a single downward path rather than the entire net= work.=20 -Regards, Joseph ---------------------------------------------------------------------- Hi everyone, Happy New Year!=20 I am trying to understand how RPL deals with broken links in non-storing mo= de so I wanted to run several scenarios by the group. When a packet is tra= nsmitted downstream and reaches a broken link, e.g., from node A to node B,= and the transmitting node (node A) doesn't get a link layer ack from the = downstream next hop (node B) after sending several retransmissions, it can = send an ICMP destination unreachable packet to the root. The root can then= try to use other routes it has to the destination or if it doesn't know of= any other ones, it can: =20 1. Increment its DTSN, triggering all nodes in the DODAG to send it = a DAO, at which point the downstream node adjacent to the broken link (node= B) will detect that the link to its parent (node A) is broken and will sel= ect a new preferred parent (assuming it has other possible parents) and sen= d a DAO. 2. Wait for the downstream node in the broken link (node B) to detect= that its parent (node A) is not reachable A. When the downstream node (Node B) observes that it hasn't gotten a = DIO from its parent (node A) for a while, and it would select a new preferr= ed parent (assuming it has other possible parents) and send a DAO to the ro= ot B. If traffic happens to be flowing upstream, the lack of per-hop/link= layer acks would indicate the upstream parent (node A) is no longer reacha= ble and a new parent will be selected, and a DAO would be sent to the root. Are these the options for detecting a broken link when forwarding a packet = downstream in non-storing mode? Is there a preferred mechanism for this? Thanks! Jorjeta= From Internet-Drafts@ietf.org Wed Jan 5 03:30:04 2011 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 7ADE13A6E1B; Wed, 5 Jan 2011 03:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, 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 KRnRcvc1BXUO; Wed, 5 Jan 2011 03:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE5E3A6D3C; Wed, 5 Jan 2011 03:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110105113001.12078.53564.idtracker@localhost> Date: Wed, 05 Jan 2011 03:30:01 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-of0-05.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: Wed, 05 Jan 2011 11:30:04 -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 Objective Function 0 Author(s) : P. Thubert Filename : draft-ietf-roll-of0-05.txt Pages : 9 Date : 2011-01-05 The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic Distance Vector protocol for Low Power and Lossy Networks (LLNs). RPL is instantiated to honor a particular routing objective/ constraint by the adding a specific Objective Function (OF) that is designed to solve that problem. This specification defines a basic OF, OF0, that uses only the abstract properties exposed in RPL messages with no metric container. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-05.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-of0-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-05032204.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Jan 5 09:30:03 2011 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 40F5D3A681C; Wed, 5 Jan 2011 09:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, 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 qkuuV2tsdopc; Wed, 5 Jan 2011 09:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7803A6C9F; Wed, 5 Jan 2011 09:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110105173001.989.61795.idtracker@localhost> Date: Wed, 05 Jan 2011 09:30:01 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-trickle-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: , X-List-Received-Date: Wed, 05 Jan 2011 17:30: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 : The Trickle Algorithm Author(s) : P. Levis, et al. Filename : draft-ietf-roll-trickle-07.txt Pages : 13 Date : 2011-01-05 The Trickle algorithm allows nodes in a lossy shared medium (e.g., low power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allows Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-07.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-trickle-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-05091905.I-D@ietf.org> --NextPart-- From Jorjeta.Jetcheva@itron.com Wed Jan 5 15:04:54 2011 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 66D5A3A6D0B for ; Wed, 5 Jan 2011 15:04:54 -0800 (PST) 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=[AWL=0.001, 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 KVF59fT7DHws for ; Wed, 5 Jan 2011 15:04:53 -0800 (PST) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by core3.amsl.com (Postfix) with ESMTP id 432383A6C5F for ; Wed, 5 Jan 2011 15:04:52 -0800 (PST) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.112]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Wed, 5 Jan 2011 15:06:59 -0800 From: "Jetcheva, Jorjeta" To: "roll@ietf.org" Date: Wed, 5 Jan 2011 15:06:56 -0800 Thread-Topic: question about broken link detection Thread-Index: AcurgTVJ2A0Msg5/SRqfG6y1HLXhvQAFXhHwAGVRtqA= Message-ID: <0368F388C03BB34BBBFA73209849D47A0656516A@ITR-EXMBXVS-2.itron.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] question about broken link detection 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 Jan 2011 23:04:54 -0000 So it seems that at the moment there is no efficient way to perform low-lat= ency broken link repair in the absence of upstream traffic? Jorjeta -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Red= dy, Joseph Sent: Monday, January 03, 2011 4:11 PM To: roll@ietf.org Subject: Re: [Roll] question about broken link detection =20 Hi Jorjeta, Option 1 will work but at the expense of lot of ( unnecessary ) traffic Option 2 has less overhead but may not work in all networks.=20 The DIO transmissions can be very rare in a static network, so lack of DIO'= s may not be a practical method to detect broken downward paths.=20 If there is upsteam traffic and missing ack's , that is certainly reason to= update the DAO parent set and send updated info to the root. But, of cours= e, this cannot be guaranteed in all networks. The reliable detection of broken downward paths can only be done by the ups= tream node. So it would be nice if there was a way for an upstream node to = initiate route repair for a single downward path rather than the entire net= work.=20 -Regards, Joseph ---------------------------------------------------------------------- Hi everyone, Happy New Year!=20 I am trying to understand how RPL deals with broken links in non-storing mo= de so I wanted to run several scenarios by the group. When a packet is tra= nsmitted downstream and reaches a broken link, e.g., from node A to node B,= and the transmitting node (node A) doesn't get a link layer ack from the = downstream next hop (node B) after sending several retransmissions, it can = send an ICMP destination unreachable packet to the root. The root can then= try to use other routes it has to the destination or if it doesn't know of= any other ones, it can: =20 1. Increment its DTSN, triggering all nodes in the DODAG to send it = a DAO, at which point the downstream node adjacent to the broken link (node= B) will detect that the link to its parent (node A) is broken and will sel= ect a new preferred parent (assuming it has other possible parents) and sen= d a DAO. 2. Wait for the downstream node in the broken link (node B) to detect= that its parent (node A) is not reachable A. When the downstream node (Node B) observes that it hasn't gotten a = DIO from its parent (node A) for a while, and it would select a new preferr= ed parent (assuming it has other possible parents) and send a DAO to the ro= ot B. If traffic happens to be flowing upstream, the lack of per-hop/link= layer acks would indicate the upstream parent (node A) is no longer reacha= ble and a new parent will be selected, and a DAO would be sent to the root. Are these the options for detecting a broken link when forwarding a packet = downstream in non-storing mode? Is there a preferred mechanism for this? Thanks! Jorjeta _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Thu Jan 6 06:17:45 2011 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 32ACA3A6DF3 for ; Thu, 6 Jan 2011 06:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.624 X-Spam-Level: X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Os2C0O9hJHD for ; Thu, 6 Jan 2011 06:17:40 -0800 (PST) Received: from smtp105.sbc.mail.ne1.yahoo.com (smtp105.sbc.mail.ne1.yahoo.com [98.138.84.183]) by core3.amsl.com (Postfix) with SMTP id 19B2D3A6E1E for ; Thu, 6 Jan 2011 06:17:40 -0800 (PST) Received: (qmail 1283 invoked from network); 6 Jan 2011 14:19:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1294323583; bh=J1PTvcf4v9V19NyNc5pFXM5NSFNuqLwtP4JnbLn1k+Q=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; b=KEeCNHTMRaFlje9MkG7yx2Mc1yAITBEKt56VHOHfDukXVXVWBZWqxb0wnac//mYJsKIQxL289KJAbhlecsAQswVQTDul9Qn1SGXFZS3a4JYH2Jys3twsxSEecW375BUHW7Kg9XEJehQW6sLaLc53yNcmXBbCBuATqMX8mm3FcR8= Received: from Studio (d.sturek@69.108.48.164 with login) by smtp105.sbc.mail.ne1.yahoo.com with SMTP; 06 Jan 2011 06:19:40 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: dzbMbPMVM1kdC8nMjX_2Yw.3EhTkhoXy7yHFkcQgDNlEtfE AtzHc8ih.VZEd2pl__RSf2mEZb8b1BB9q23fW3NMrQWp50uMyRs7ab5LF233 nxHejNb1QlY5znEM9Qo1vEkGXvsYTx_yr77op.fTyIrKSP.gXdMbQwGyiAWD NN8dlRZ3fLtGn5M2rKf_IVdzWZ6b.wAztmz3I0dg5778E3T3ePgp7MxifppW Kc7myJR2IxhFaizGHM8bhaZakxg7ZprIk7ghvx.v6VMkDJdJGAxBi_d8a7Gm JaG67.eFllDgWfqOFrRlNwGMcx4._uZ7q7GF8kwaXF9WRc3.ddO7xAlis_z5 2DLw- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Jetcheva, Jorjeta'" , References: <0368F388C03BB34BBBFA73209849D47A063CC3A8@ITR-EXMBXVS-2.itron.com> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A063CC3A8@ITR-EXMBXVS-2.itron.com> Date: Thu, 6 Jan 2011 06:19:33 -0800 Message-ID: <007001cbadac$be545890$3afd09b0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01CBAD69.B0311890" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcurelGPfOoVdv2LTtCiRV+fh7U09ACMh72Q Content-Language: en-us Subject: Re: [Roll] question about broken link detection 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: Thu, 06 Jan 2011 14:17:45 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0071_01CBAD69.B0311890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jorjeta, I think the point to point draft (http://datatracker.ietf.org/doc/draft-dt-roll-p2p-rpl/) attempts to take up the issue of pro-active route repair using RPL. I have not closely followed the draft but know that was in scope. Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jetcheva, Jorjeta Sent: Monday, January 03, 2011 11:14 AM To: roll@ietf.org Subject: [Roll] question about broken link detection Hi everyone, Happy New Year! I am trying to understand how RPL deals with broken links in non-storing mode so I wanted to run several scenarios by the group. When a packet is transmitted downstream and reaches a broken link, e.g., from node A to node B, and the transmitting node (node A) doesn't get a link layer ack from the downstream next hop (node B) after sending several retransmissions, it can send an ICMP destination unreachable packet to the root. The root can then try to use other routes it has to the destination or if it doesn't know of any other ones, it can: 1. Increment its DTSN, triggering all nodes in the DODAG to send it a DAO, at which point the downstream node adjacent to the broken link (node B) will detect that the link to its parent (node A) is broken and will select a new preferred parent (assuming it has other possible parents) and send a DAO. 2. Wait for the downstream node in the broken link (node B) to detect that its parent (node A) is not reachable A. When the downstream node (Node B) observes that it hasn't gotten a DIO from its parent (node A) for a while, and it would select a new preferred parent (assuming it has other possible parents) and send a DAO to the root B. If traffic happens to be flowing upstream, the lack of per-hop/link layer acks would indicate the upstream parent (node A) is no longer reachable and a new parent will be selected, and a DAO would be sent to the root. Are these the options for detecting a broken link when forwarding a packet downstream in non-storing mode? Is there a preferred mechanism for this? Thanks! Jorjeta ------=_NextPart_000_0071_01CBAD69.B0311890 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jorjeta,

 

I think the point to = point draft (http://da= tatracker.ietf.org/doc/draft-dt-roll-p2p-rpl/) attempts to take up = the issue of pro-active route repair using RPL.   I have not = closely followed the draft but know that was in = scope.

 

Don

 

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jetcheva, Jorjeta
Sent: Monday, January 03, 2011 11:14 = AM
To: roll@ietf.org
Subject: [Roll] question about = broken link detection

 

Hi = everyone,

 

Happy New Year!

 

I am trying = to understand how RPL deals with broken links in non-storing mode so I = wanted to run several scenarios by the group.  When a packet is = transmitted downstream and reaches a broken link, e.g., from node A to = node B,  and the transmitting node (node A) doesn’t get a = link layer ack from the downstream next hop (node B) after sending = several retransmissions, it can send an ICMP destination unreachable = packet to the root.  The root can then try to use other routes it = has to the destination or if it doesn’t know of any other ones, it = can:

 

1.       =  Increment its DTSN, triggering all nodes = in the DODAG to send it a DAO, at which point the downstream node = adjacent to the broken link (node B) will detect that the link to its = parent (node A) is broken and will select a new preferred parent = (assuming it has other possible parents) and send a = DAO.

2.       = Wait for the downstream node in the broken link = (node B) to detect that its parent (node A) is not reachable =

A.      = When the downstream node (Node B) observes that = it hasn’t gotten a DIO from its parent (node A) for a while, and = it would select a new preferred parent (assuming it has other possible = parents) and send a DAO to the root

B.      = If traffic happens to be flowing upstream, the = lack of per-hop/link layer acks would indicate the upstream parent (node = A) is no longer reachable and a new parent will be selected, and a DAO = would be sent to the root.

Are these = the options for detecting a broken link when forwarding a packet = downstream in non-storing mode?  Is there a preferred mechanism for = this?

 

Thanks!

 

Jorjeta

------=_NextPart_000_0071_01CBAD69.B0311890-- From Jerald.P.Martocci@jci.com Thu Jan 6 07:39:04 2011 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 672083A6C33; Thu, 6 Jan 2011 07:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.281 X-Spam-Level: X-Spam-Status: No, score=-4.281 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599, 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 y8Mg20vtZoht; Thu, 6 Jan 2011 07:38:59 -0800 (PST) Received: from exprod8og101.obsmtp.com (exprod8og101.obsmtp.com [64.18.3.82]) by core3.amsl.com (Postfix) with ESMTP id 20BF43A67D4; Thu, 6 Jan 2011 07:38:57 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob101.postini.com ([64.18.7.12]) with SMTP ID DSNKTSXij3QYuUb82HiBYavfGC9zHmpTL/EN@postini.com; Thu, 06 Jan 2011 07:41:05 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2011010609411459-322906 ; Thu, 6 Jan 2011 09:41:14 -0600 In-Reply-To: <007001cbadac$be545890$3afd09b0$@sturek@att.net> References: <0368F388C03BB34BBBFA73209849D47A063CC3A8@ITR-EXMBXVS-2.itron.com> <007001cbadac$be545890$3afd09b0$@sturek@att.net> To: d.sturek@att.net MIME-Version: 1.0 X-KeepSent: 3B25D179:981E6326-86257810:0054C68A; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 FP4 December 11, 2009 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 6 Jan 2011 09:40:53 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 01/06/2011 09:39:58 AM, Serialize complete at 01/06/2011 09:39:58 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 01/06/2011 09:41:14 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 01/06/2011 09:41:23 AM, Serialize complete at 01/06/2011 09:41:23 AM Content-Type: multipart/related; boundary="=_related 0056241C86257810_=" Cc: roll@ietf.org, roll-bounces@ietf.org, "'Jetcheva, Jorjeta'" Subject: Re: [Roll] question about broken link detection 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 Jan 2011 15:39:04 -0000 This is a multipart message in MIME format. --=_related 0056241C86257810_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Hi Jorjeta,

The P2P mechanism could be deployed as a band-aid means to repair the link in the DAG, but it is not meant for that.  If node A wants to transmit to node B within the LLN, RPL (in non-storing mode) would require the packet to traverse to the LBR and then be source routed back down to the destination.  If the packet should happen upon a broken link, it would be feasible that a P2P request could be made at that point to re-establish a link and complete the journey.  However since P2P is not an integral part of RPL, this would be a proprietary solution.  The packet would get to the destination, but the LBR would not know about the broken link so there would be no persisten= ce of this link repair.

The more likely scenario would be th= at Node A sends a packet to Node B via the LBR as noted above.  Node A times out the Node B response and determines the packet has been lost.  Rather than continue to retry through the DAG and LBR hoping the link has been re-established; Node A rather defines a direct link to Node B using the P2P mechanism.  Here, rather than traversing the entire DAG up and down through the LBR, the packet can be efficiently sent directly from A to B through the appropriate hopping nodes.

This is the intent of the P2P draft.  Hope this helps.

Jerry





From: "Don Sturek" <d.sturek@= att.net>
To: "'Jetcheva, Jorjeta'" <= Jorjeta.Jetcheva@itron.com>, <roll@ietf.org>
Date: 01/06/2011 08:20 AM
Subject: Re: [Roll] question about broken link detection




Hi Jorjeta,
 
I think the point to po= int draft (http://datatracker.ie= tf.org/doc/draft-dt-roll-p2p-rpl/) attempts to take up the issue of pro-active route repair using RPL.   I have not closely followed the draft but know that was in scope.
 
Don
 
 
From: roll-bounces@ietf.org [= mailto:roll-bounces@ietf.org] On Behalf Of Jetcheva, Jorjeta
Sent: Monday, January 03, 2011 11:14 AM
To: roll@ietf.org
Subject: [Roll] question about broken link detection
 
Hi everyone,
 
Happy New Year!
 
I am trying to understand how RPL deals with broken links in non-storing mode so I wanted to run several scenarios by the group.  When a packet is transmitted downstream and reaches a broken link, e.g., from node A to node B,  and the transmitting node (node A) doesn’t get a link layer ack from the downstream next h= op (node B) after sending several retransmissions, it can send an ICMP destina= tion unreachable packet to the root.  The root can then try to use other routes it has to the destination or if it doesn’t know of any other o= nes, it can:
 
1.        Increment its DTSN, triggering all nodes in the DODAG to send it a DAO, at which point the downstream node adjacent to the broken link (node B) will detect that the link to its parent (node A) is broken and will select a new prefer= red parent (assuming it has other possible parents) and send a DAO.
2.       Wait for the do= wnstream node in the broken link (node B) to detect that its parent (node A) is not reachable
A.      When the downstr= eam node (Node B) observes that it hasn’t gotten a DIO from its parent (n= ode A) for a while, and it would select a new preferred parent (assuming it has other possible parents) and send a DAO to the root
B.      If traffic happe= ns to be flowing upstream, the lack of per-hop/link layer acks would indicate the upstream parent (node A) is no longer reachable and a new parent will be selected, and a DAO would be sent to the root.
Are these the options for detecting a b= roken link when forwarding a packet downstream in non-storing mode?  Is there a preferred mechanism for this?
 
Thanks!
 
Jorjeta=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/listinfo/roll

--=_related 0056241C86257810_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_0928FDA00928FB600056241C86257810> /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 0056241C86257810_=-- From prvs=98180c54b=mukul@uwm.edu Thu Jan 6 18:01:16 2011 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 92B053A6D1C for ; Thu, 6 Jan 2011 18:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 5FEYkDvJIyMG for ; Thu, 6 Jan 2011 18:01:15 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 59F313A6E4A for ; Thu, 6 Jan 2011 18:01:15 -0800 (PST) Received: from mta02.pantherlink.uwm.edu ([129.89.7.133]) by ip1mta.uwm.edu with ESMTP; 06 Jan 2011 20:03:21 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 065B412E3BC; Thu, 6 Jan 2011 20:03:22 -0600 (CST) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu 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 x2V5uVW+QRtF; Thu, 6 Jan 2011 20:03:21 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 7EFDC12E3BA; Thu, 6 Jan 2011 20:03:21 -0600 (CST) Date: Thu, 6 Jan 2011 20:03:21 -0600 (CST) From: Mukul Goyal To: Jorjeta Jetcheva Message-ID: <476501960.1337096.1294365801422.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A0656516A@ITR-EXMBXVS-2.itron.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 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] question about broken link detection 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 Jan 2011 02:01:16 -0000 Hi Jorjeta As Don and Jerry pointed out, the P2P mechanism can be used to discover "on demand" a new route from a source to a destination. But, the P2P mechanism does not repair an existing DAG. It creates a brand new temporary DAG for the purpose of propagating the discovery message. Thanks Mukul ----- Original Message ----- From: "Jorjeta Jetcheva" To: roll@ietf.org Sent: Wednesday, January 5, 2011 5:06:56 PM Subject: Re: [Roll] question about broken link detection So it seems that at the moment there is no efficient way to perform low-latency broken link repair in the absence of upstream traffic? Jorjeta -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Reddy, Joseph Sent: Monday, January 03, 2011 4:11 PM To: roll@ietf.org Subject: Re: [Roll] question about broken link detection Hi Jorjeta, Option 1 will work but at the expense of lot of ( unnecessary ) traffic Option 2 has less overhead but may not work in all networks. The DIO transmissions can be very rare in a static network, so lack of DIO's may not be a practical method to detect broken downward paths. If there is upsteam traffic and missing ack's , that is certainly reason to update the DAO parent set and send updated info to the root. But, of course, this cannot be guaranteed in all networks. The reliable detection of broken downward paths can only be done by the upstream node. So it would be nice if there was a way for an upstream node to initiate route repair for a single downward path rather than the entire network. -Regards, Joseph ---------------------------------------------------------------------- Hi everyone, Happy New Year! I am trying to understand how RPL deals with broken links in non-storing mode so I wanted to run several scenarios by the group. When a packet is transmitted downstream and reaches a broken link, e.g., from node A to node B, and the transmitting node (node A) doesn't get a link layer ack from the downstream next hop (node B) after sending several retransmissions, it can send an ICMP destination unreachable packet to the root. The root can then try to use other routes it has to the destination or if it doesn't know of any other ones, it can: 1. Increment its DTSN, triggering all nodes in the DODAG to send it a DAO, at which point the downstream node adjacent to the broken link (node B) will detect that the link to its parent (node A) is broken and will select a new preferred parent (assuming it has other possible parents) and send a DAO. 2. Wait for the downstream node in the broken link (node B) to detect that its parent (node A) is not reachable A. When the downstream node (Node B) observes that it hasn't gotten a DIO from its parent (node A) for a while, and it would select a new preferred parent (assuming it has other possible parents) and send a DAO to the root B. If traffic happens to be flowing upstream, the lack of per-hop/link layer acks would indicate the upstream parent (node A) is no longer reachable and a new parent will be selected, and a DAO would be sent to the root. Are these the options for detecting a broken link when forwarding a packet downstream in non-storing mode? Is there a preferred mechanism for this? Thanks! Jorjeta _______________________________________________ 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 daniel.gavelle@nxp.com Fri Jan 7 07:25:51 2011 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 448423A6900; Fri, 7 Jan 2011 07:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 pLuHRawyOQJ8; Fri, 7 Jan 2011 07:25:50 -0800 (PST) Received: from be1ssnxpe2.nxp.com (be1ssnxpe2.nxp.com [57.67.164.70]) by core3.amsl.com (Postfix) with ESMTP id A473E3A68F5; Fri, 7 Jan 2011 07:25:49 -0800 (PST) Received: from EU1RDCRDC1VW025.exi.nxp.com ([134.27.176.170]) by be1ssnxpe2.nxp.com (8.14.3/8.14.3) with ESMTP id p07FRth3026749 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Jan 2011 16:27:55 +0100 Received: from eu1rdcrdc1wx032.exi.nxp.com ([134.27.179.186]) by EU1RDCRDC1VW025.exi.nxp.com ([134.27.176.170]) with mapi; Fri, 7 Jan 2011 16:27:55 +0100 From: Daniel Gavelle To: "roll@ietf.org" , "ipv6@ietf.org" Date: Fri, 7 Jan 2011 16:27:53 +0100 Thread-Topic: Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01 Thread-Index: AcuufmaG0pqVYcizQIi6P/58PErhOAAADbtg Message-ID: <78B923726E7D59429936580CF127E943A13214D942@eu1rdcrdc1wx032.exi.nxp.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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-07_07:2011-01-07, 2011-01-07, 1970-01-01 signatures=0 Subject: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-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: Fri, 07 Jan 2011 15:25:51 -0000 A discrepancy between the ROLL and 6man-rpl-routing-header draft was spotte= d a few weeks ago. I haven't seen any comments on this on the ROLL list. = I've posted it to the 6Man list as it also affects a draft in this WG. It = is important that everyone generates the destination unreachable in the sam= e way because the RPL root node will process the destination unreachable to= determine which link has failed. Daniel. -------- Original Message -------- Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt Date: Fri, 17 Dec 2010 14:40:24 -0800 From: Dario Tedeschi To: Internet-Drafts@ietf.org CC: roll@ietf.org, i-d-announce@ietf.org References: <20101215230001.30256.8767.idtracker@localhost> There seems to be a discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01: The following pseudo code in the RPL RH draft: else if i < n and Address[i] is not on-link { send an ICMP Destination Unreachable, Code 7, message to <--*** the Source Address and discard the packet } else { swap the IPv6 Destination Address and Address[i] <--*** if the IPv6 Hop Limit is less than or equal to 1 { send an ICMP Time Exceeded -- Hop Limit Exceeded in Transit message to the Source Address and discard the packet } does not correlate with the following wording in the RPL draft (section 11.2.2.3): .... .... The "Error in Source Routing Header" message has the same format as the "Destination Unreachable Message" as specified in [RFC4443]. The portion of the invoking packet that is sent back in the ICMP message should record at least up to the routing header, and the routing header should be consumed by this node so that the destination in the IPv6 header is the next hop that this node could <--*** not reach. Dario On 15/12/2010 3:00 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Routing Over Low power and Lossy network= s Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Net= works > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-17.txt > Pages : 159 > Date : 2010-12-15 > > Low power and Lossy Networks (LLNs) are a class of network in which=20 > both the routers and their interconnect are constrained. LLN routers=20 > typically operate with constraints on processing power, memory, and=20 > energy (battery power). Their interconnects are characterized by high=20 > loss rates, low data rates, and instability. LLNs are comprised of=20 > anything from a few dozen and up to thousands of routers. > Supported traffic flows include point-to-point (between devices inside=20 > the LLN), point-to-multipoint (from a central control point to a=20 > subset of devices inside the LLN), and multipoint-to-point (from=20 > devices inside the LLN towards a central control point). This=20 > document specifies the IPv6 Routing Protocol for LLNs (RPL), which=20 > provides a mechanism whereby multipoint-to-point traffic from devices=20 > inside the LLN towards a central control point, as well as point-to-=20 > multipoint traffic from the central control point to the devices=20 > inside the LLN, is supported. Support for point-to-point traffic is=20 > also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-17.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=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll Regards, Daniel. --=20 __________________________________________________ Daniel Gavelle, Software Team Leader Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors Furnival S= treet, Sheffield, S1 4QT, UK Tel: +44 114 281 2655 Fax: +44 114 281 2951 Comp Reg No: 3191371 - Registered In England http://www.nxp.com http://www.= jennic.com __________________________________________________ From pthubert@cisco.com Fri Jan 7 08:42:14 2011 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 BB4D73A6842; Fri, 7 Jan 2011 08:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.32 X-Spam-Level: X-Spam-Status: No, score=-10.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 pYb2yL8Oc2fP; Fri, 7 Jan 2011 08:42:13 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6634E3A6909; Fri, 7 Jan 2011 08:42:13 -0800 (PST) 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: AvsEANrRJk2rR7Hu/2dsb2JhbACkKHOjP5gKgw6CPgSOLQ Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 07 Jan 2011 16:44:20 +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 p07GiG8C024730; Fri, 7 Jan 2011 16:44:19 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 17:44:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jan 2011 17:44:14 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0385FB77@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01 Thread-Index: Acuuih1S3RQmBlNQTJyUzPtsXKbWjg== From: "Pascal Thubert (pthubert)" To: "Daniel Gavelle" , , X-OriginalArrivalTime: 07 Jan 2011 16:44:17.0057 (UTC) FILETIME=[1FB07910:01CBAE8A] Subject: Re: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-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: Fri, 07 Jan 2011 16:42:14 -0000 Hi Daniel: Thanks for the heads up. The text in RPL assumes that the node receives a packet, processes the RH (swaps the destination) and then forwards to the new next hop. If that fails, it seems easier to pass the resulting packet as it now stands than to recomputed the packet as it was received. I think the RH draft should adapt to that . Would you agree? Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Daniel Gavelle > Sent: Friday, January 07, 2011 4:28 PM > To: roll@ietf.org; ipv6@ietf.org > Subject: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf- > 6man-rpl-routing-header-01 >=20 > A discrepancy between the ROLL and 6man-rpl-routing-header draft was > spotted a few weeks ago. I haven't seen any comments on this on the ROLL > list. I've posted it to the 6Man list as it also affects a draft in this WG. It is > important that everyone generates the destination unreachable in the same > way because the RPL root node will process the destination unreachable to > determine which link has failed. >=20 > Daniel. >=20 >=20 > -------- Original Message -------- > Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt > Date: Fri, 17 Dec 2010 14:40:24 -0800 > From: Dario Tedeschi > To: Internet-Drafts@ietf.org > CC: roll@ietf.org, i-d-announce@ietf.org > References: <20101215230001.30256.8767.idtracker@localhost> >=20 >=20 >=20 > There seems to be a discrepancy between draft-ietf-roll-rpl-17 and > draft-ietf-6man-rpl-routing-header-01: >=20 > The following pseudo code in the RPL RH draft: >=20 > else if i < n and Address[i] is not on-link { > send an ICMP Destination Unreachable, Code 7, message to > <--*** > the Source Address and discard the packet > } > else { > swap the IPv6 Destination Address and Address[i] <--*** >=20 > if the IPv6 Hop Limit is less than or equal to 1 { > send an ICMP Time Exceeded -- Hop Limit Exceeded in > Transit message to the Source Address and discard the > packet > } >=20 >=20 > does not correlate with the following wording in the RPL draft (section > 11.2.2.3): >=20 > .... .... The "Error in Source Routing Header" > message has the > same format as the "Destination Unreachable Message" as specified in > [RFC4443]. The portion of the invoking packet that is sent back in > the ICMP message should record at least up to the routing header, and > the routing header should be consumed by this node so that the > destination in the IPv6 header is the next hop that this node could > <--*** > not reach. >=20 >=20 >=20 > Dario >=20 >=20 > On 15/12/2010 3:00 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-17.txt > > Pages : 159 > > Date : 2010-12-15 > > > > 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 processing power, memory, and > > energy (battery power). Their interconnects are characterized by high > > loss rates, low data rates, and instability. LLNs are comprised of > > anything from a few dozen and up to thousands of routers. > > Supported traffic flows include point-to-point (between devices inside > > the LLN), point-to-multipoint (from a central control point to a > > subset of devices inside the LLN), and multipoint-to-point (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-17.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 >=20 >=20 >=20 > Regards, >=20 > Daniel. >=20 > -- >=20 > __________________________________________________ >=20 > Daniel Gavelle, Software Team Leader > Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors Furnival > Street, Sheffield, S1 4QT, UK > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Comp Reg No: 3191371 - Registered In England http://www.nxp.com > http://www.jennic.com > __________________________________________________ > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From daniel.gavelle@nxp.com Fri Jan 7 09:31:07 2011 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 6FD2E3A693E; Fri, 7 Jan 2011 09:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 N-2-p6X+B1-V; Fri, 7 Jan 2011 09:31:04 -0800 (PST) Received: from be1ssnxpe2.nxp.com (be1ssnxpe2.nxp.com [57.67.164.70]) by core3.amsl.com (Postfix) with ESMTP id E00103A6921; Fri, 7 Jan 2011 09:31:03 -0800 (PST) Received: from EU1RDCRDC1VW024.exi.nxp.com ([134.27.176.169]) by be1ssnxpe2.nxp.com (8.14.3/8.14.3) with ESMTP id p07HX5LN029399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Jan 2011 18:33:06 +0100 Received: from eu1rdcrdc1wx032.exi.nxp.com ([134.27.179.186]) by EU1RDCRDC1VW024.exi.nxp.com ([134.27.176.169]) with mapi; Fri, 7 Jan 2011 18:33:05 +0100 From: Daniel Gavelle To: "Pascal Thubert (pthubert)" , "roll@ietf.org" , "ipv6@ietf.org" Date: Fri, 7 Jan 2011 18:33:05 +0100 Thread-Topic: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01 Thread-Index: Acuuih1S3RQmBlNQTJyUzPtsXKbWjgABdWyg Message-ID: <78B923726E7D59429936580CF127E943A13214DDC4@eu1rdcrdc1wx032.exi.nxp.com> References: <6A2A459175DABE4BB11DE2026AA50A5D0385FB77@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0385FB77@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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-07_08:2011-01-07, 2011-01-07, 1970-01-01 signatures=0 Subject: Re: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-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: Fri, 07 Jan 2011 17:31:07 -0000 Pascal, I agree that it is easier to swap the header before generating the response= . It also makes parsing the response on the root node easier, as the desti= nation address will be the address of the node that is no longer reachable.= =20 Daniel. -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: 07 January 2011 16:44 To: Daniel Gavelle; roll@ietf.org; ipv6@ietf.org Subject: RE: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ie= tf-6man-rpl-routing-header-01 Hi Daniel: Thanks for the heads up. The text in RPL assumes that the node receives a packet, processes the RH (swaps the destination) and then forwards to the new next hop. If that fails, it seems easier to pass the resulting packet as it now stands than to recomputed the packet as it was received. I think the RH draft should adapt to that . Would you agree? Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Daniel Gavelle > Sent: Friday, January 07, 2011 4:28 PM > To: roll@ietf.org; ipv6@ietf.org > Subject: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf- > 6man-rpl-routing-header-01 >=20 > A discrepancy between the ROLL and 6man-rpl-routing-header draft was > spotted a few weeks ago. I haven't seen any comments on this on the ROLL > list. I've posted it to the 6Man list as it also affects a draft in this WG. It is > important that everyone generates the destination unreachable in the same > way because the RPL root node will process the destination unreachable to > determine which link has failed. >=20 > Daniel. >=20 >=20 > -------- Original Message -------- > Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt > Date: Fri, 17 Dec 2010 14:40:24 -0800 > From: Dario Tedeschi > To: Internet-Drafts@ietf.org > CC: roll@ietf.org, i-d-announce@ietf.org > References: <20101215230001.30256.8767.idtracker@localhost> >=20 >=20 >=20 > There seems to be a discrepancy between draft-ietf-roll-rpl-17 and > draft-ietf-6man-rpl-routing-header-01: >=20 > The following pseudo code in the RPL RH draft: >=20 > else if i < n and Address[i] is not on-link { > send an ICMP Destination Unreachable, Code 7, message to > <--*** > the Source Address and discard the packet > } > else { > swap the IPv6 Destination Address and Address[i] <--*** >=20 > if the IPv6 Hop Limit is less than or equal to 1 { > send an ICMP Time Exceeded -- Hop Limit Exceeded in > Transit message to the Source Address and discard the > packet > } >=20 >=20 > does not correlate with the following wording in the RPL draft (section > 11.2.2.3): >=20 > .... .... The "Error in Source Routing Header" > message has the > same format as the "Destination Unreachable Message" as specified in > [RFC4443]. The portion of the invoking packet that is sent back in > the ICMP message should record at least up to the routing header, and > the routing header should be consumed by this node so that the > destination in the IPv6 header is the next hop that this node could > <--*** > not reach. >=20 >=20 >=20 > Dario >=20 >=20 > On 15/12/2010 3:00 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-17.txt > > Pages : 159 > > Date : 2010-12-15 > > > > 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 processing power, memory, and > > energy (battery power). Their interconnects are characterized by high > > loss rates, low data rates, and instability. LLNs are comprised of > > anything from a few dozen and up to thousands of routers. > > Supported traffic flows include point-to-point (between devices inside > > the LLN), point-to-multipoint (from a central control point to a > > subset of devices inside the LLN), and multipoint-to-point (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-17.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 >=20 >=20 >=20 > Regards, >=20 > Daniel. >=20 > -- >=20 > __________________________________________________ >=20 > Daniel Gavelle, Software Team Leader > Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors Furnival > Street, Sheffield, S1 4QT, UK > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Comp Reg No: 3191371 - Registered In England http://www.nxp.com > http://www.jennic.com > __________________________________________________ > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From dat@exegin.com Fri Jan 7 13:33:51 2011 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 142A13A69B3; Fri, 7 Jan 2011 13:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 94mzeXDfmRWG; Fri, 7 Jan 2011 13:33:47 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 953D23A69B2; Fri, 7 Jan 2011 13:30:43 -0800 (PST) Received: by wwa36 with SMTP id 36so17902762wwa.13 for ; Fri, 07 Jan 2011 13:32:49 -0800 (PST) Received: by 10.227.154.69 with SMTP id n5mr15854150wbw.131.1294435968357; Fri, 07 Jan 2011 13:32:48 -0800 (PST) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id o51sm12681404wes.39.2011.01.07.13.32.45 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 13:32:47 -0800 (PST) Message-ID: <4D278689.8090509@exegin.com> Date: Fri, 07 Jan 2011 13:32:57 -0800 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Daniel Gavelle References: <6A2A459175DABE4BB11DE2026AA50A5D0385FB77@XMB-AMS-107.cisco.com> <78B923726E7D59429936580CF127E943A13214DDC4@eu1rdcrdc1wx032.exi.nxp.com> In-Reply-To: <78B923726E7D59429936580CF127E943A13214DDC4@eu1rdcrdc1wx032.exi.nxp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , "roll@ietf.org" Subject: Re: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-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: Fri, 07 Jan 2011 21:33:51 -0000 I second that. On 07/01/2011 9:33 AM, Daniel Gavelle wrote: > Pascal, > > I agree that it is easier to swap the header before generating the response. It also makes parsing the response on the root node easier, as the destination address will be the address of the node that is no longer reachable. > > Daniel. > > > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: 07 January 2011 16:44 > To: Daniel Gavelle; roll@ietf.org; ipv6@ietf.org > Subject: RE: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01 > > Hi Daniel: > > Thanks for the heads up. > > The text in RPL assumes that the node receives a packet, processes the > RH (swaps the destination) and then forwards to the new next hop. If > that fails, it seems easier to pass the resulting packet as it now > stands than to recomputed the packet as it was received. I think the RH > draft should adapt to that . Would you agree? > > Pascal > http://www.xtranormal.com/watch/7011357/ > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Daniel Gavelle >> Sent: Friday, January 07, 2011 4:28 PM >> To: roll@ietf.org; ipv6@ietf.org >> Subject: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and > draft-ietf- >> 6man-rpl-routing-header-01 >> >> A discrepancy between the ROLL and 6man-rpl-routing-header draft was >> spotted a few weeks ago. I haven't seen any comments on this on the > ROLL >> list. I've posted it to the 6Man list as it also affects a draft in > this WG. It is >> important that everyone generates the destination unreachable in the > same >> way because the RPL root node will process the destination unreachable > to >> determine which link has failed. >> >> Daniel. >> >> >> -------- Original Message -------- >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt >> Date: Fri, 17 Dec 2010 14:40:24 -0800 >> From: Dario Tedeschi >> To: Internet-Drafts@ietf.org >> CC: roll@ietf.org, i-d-announce@ietf.org >> References: <20101215230001.30256.8767.idtracker@localhost> >> >> >> >> There seems to be a discrepancy between draft-ietf-roll-rpl-17 and >> draft-ietf-6man-rpl-routing-header-01: >> >> The following pseudo code in the RPL RH draft: >> >> else if i< n and Address[i] is not on-link { >> send an ICMP Destination Unreachable, Code 7, message to >> <--*** >> the Source Address and discard the packet >> } >> else { >> swap the IPv6 Destination Address and Address[i] > <--*** >> if the IPv6 Hop Limit is less than or equal to 1 { >> send an ICMP Time Exceeded -- Hop Limit Exceeded in >> Transit message to the Source Address and discard the >> packet >> } >> >> >> does not correlate with the following wording in the RPL draft > (section >> 11.2.2.3): >> >> .... .... The "Error in Source Routing Header" >> message has the >> same format as the "Destination Unreachable Message" as specified > in >> [RFC4443]. The portion of the invoking packet that is sent back > in >> the ICMP message should record at least up to the routing header, > and >> the routing header should be consumed by this node so that the >> destination in the IPv6 header is the next hop that this node > could >> <--*** >> not reach. >> >> >> >> Dario >> >> >> On 15/12/2010 3:00 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-17.txt >>> Pages : 159 >>> Date : 2010-12-15 >>> >>> 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 processing power, memory, and >>> energy (battery power). Their interconnects are characterized by > high >>> loss rates, low data rates, and instability. LLNs are comprised of >>> anything from a few dozen and up to thousands of routers. >>> Supported traffic flows include point-to-point (between devices > inside >>> the LLN), point-to-multipoint (from a central control point to a >>> subset of devices inside the LLN), and multipoint-to-point (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-17.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 >> >> >> Regards, >> >> Daniel. >> >> -- >> >> __________________________________________________ >> >> Daniel Gavelle, Software Team Leader >> Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors > Furnival >> Street, Sheffield, S1 4QT, UK >> Tel: +44 114 281 2655 >> Fax: +44 114 281 2951 >> Comp Reg No: 3191371 - Registered In England http://www.nxp.com >> http://www.jennic.com >> __________________________________________________ >> _______________________________________________ >> 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 Jorjeta.Jetcheva@itron.com Fri Jan 7 16:18:53 2011 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 759A43A69A1 for ; Fri, 7 Jan 2011 16:18:53 -0800 (PST) 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=[AWL=0.000, 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 3dnhPcQ-Q8st for ; Fri, 7 Jan 2011 16:18:52 -0800 (PST) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by core3.amsl.com (Postfix) with ESMTP id 3D7503A6961 for ; Fri, 7 Jan 2011 16:18:48 -0800 (PST) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.112]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Fri, 7 Jan 2011 16:19:34 -0800 From: "Jetcheva, Jorjeta" To: Mukul Goyal Date: Fri, 7 Jan 2011 16:19:32 -0800 Thread-Topic: [Roll] question about broken link detection Thread-Index: AcuuDxSDbqILClqoQF26FcxLo8k8tgAuj1hQ Message-ID: <0368F388C03BB34BBBFA73209849D47A0683D62D@ITR-EXMBXVS-2.itron.com> References: <0368F388C03BB34BBBFA73209849D47A0656516A@ITR-EXMBXVS-2.itron.com> <476501960.1337096.1294365801422.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <476501960.1337096.1294365801422.JavaMail.root@mail02.pantherlink.uwm.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] question about broken link detection 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, 08 Jan 2011 00:18:53 -0000 SGkgZXZlcnlvbmUsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBpbnB1dC4gSSB0aGluayB0aGF0IHRo ZSBiYXNpYyByb3V0ZSByZXBhaXIgbWVjaGFuaXNtcyBzaG91bGQgYmUgZGVmaW5lZCBhcyBwYXJ0 IG9mIHRoZSBiYXNlIFJQTCBwcm90b2NvbC4gIFBlcmhhcHMgdGhpcyBpcyBhbm90aGVyIGl0ZW0g Zm9yIHRoZSByZS1jaGFydGVyaW5nIHRvLWRvIGxpc3QuICBTb2x2aW5nIHRoaXMgcHJvYmxlbSBz aG91bGQgZWxpbWluYXRlIHRoZSBuZWVkIGZvciBwcm9hY3RpdmUgbmVpZ2hib3IgYWRqYWNlbmN5 IGRldGVjdGlvbiBtZWNoYW5pc21zLiANCg0KSm9yamV0YQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogTXVrdWwgR295YWwgW21haWx0bzptdWt1bEB1d20uZWR1XSANClNlbnQ6 IFRodXJzZGF5LCBKYW51YXJ5IDA2LCAyMDExIDY6MDMgUE0NClRvOiBKZXRjaGV2YSwgSm9yamV0 YQ0KQ2M6IHJvbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbUm9sbF0gcXVlc3Rpb24gYWJvdXQg YnJva2VuIGxpbmsgZGV0ZWN0aW9uDQoNCg0KSGkgSm9yamV0YQ0KDQpBcyBEb24gYW5kIEplcnJ5 IHBvaW50ZWQgb3V0LCB0aGUgUDJQIG1lY2hhbmlzbSBjYW4gYmUgdXNlZCB0byBkaXNjb3ZlciAi b24gZGVtYW5kIiBhIG5ldyByb3V0ZSBmcm9tIGEgc291cmNlIHRvIGEgZGVzdGluYXRpb24uIEJ1 dCwgdGhlIFAyUCBtZWNoYW5pc20gZG9lcyBub3QgcmVwYWlyIGFuIGV4aXN0aW5nIERBRy4gSXQg Y3JlYXRlcyBhIGJyYW5kIG5ldyB0ZW1wb3JhcnkgREFHIGZvciB0aGUgcHVycG9zZSBvZiBwcm9w YWdhdGluZyB0aGUgZGlzY292ZXJ5IG1lc3NhZ2UuDQoNClRoYW5rcw0KTXVrdWwNCg0KLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkpvcmpldGEgSmV0Y2hldmEiIDxKb3JqZXRh LkpldGNoZXZhQGl0cm9uLmNvbT4NClRvOiByb2xsQGlldGYub3JnDQpTZW50OiBXZWRuZXNkYXks IEphbnVhcnkgNSwgMjAxMSA1OjA2OjU2IFBNDQpTdWJqZWN0OiBSZTogW1JvbGxdIHF1ZXN0aW9u IGFib3V0IGJyb2tlbiBsaW5rIGRldGVjdGlvbg0KDQpTbyBpdCBzZWVtcyB0aGF0IGF0IHRoZSBt b21lbnQgdGhlcmUgaXMgbm8gZWZmaWNpZW50IHdheSB0byBwZXJmb3JtIGxvdy1sYXRlbmN5IGJy b2tlbiBsaW5rIHJlcGFpciBpbiB0aGUgYWJzZW5jZSBvZiB1cHN0cmVhbSB0cmFmZmljPw0KDQpK b3JqZXRhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiByb2xsLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSZWRk eSwgSm9zZXBoDQpTZW50OiBNb25kYXksIEphbnVhcnkgMDMsIDIwMTEgNDoxMSBQTQ0KVG86IHJv bGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbUm9sbF0gcXVlc3Rpb24gYWJvdXQgYnJva2VuIGxp bmsgZGV0ZWN0aW9uDQoNCiANCg0KSGkgSm9yamV0YSwNCg0KT3B0aW9uIDEgd2lsbCB3b3JrIGJ1 dCBhdCB0aGUgZXhwZW5zZSBvZiBsb3Qgb2YgKCB1bm5lY2Vzc2FyeSApIHRyYWZmaWMNCg0KT3B0 aW9uIDIgaGFzIGxlc3Mgb3ZlcmhlYWQgYnV0IG1heSBub3Qgd29yayBpbiBhbGwgbmV0d29ya3Mu IA0KVGhlIERJTyB0cmFuc21pc3Npb25zIGNhbiBiZSB2ZXJ5IHJhcmUgaW4gYSBzdGF0aWMgbmV0 d29yaywgc28gbGFjayBvZiBESU8ncyBtYXkgbm90IGJlIGEgcHJhY3RpY2FsIG1ldGhvZCB0byBk ZXRlY3QgYnJva2VuIGRvd253YXJkIHBhdGhzLiANCklmIHRoZXJlIGlzIHVwc3RlYW0gdHJhZmZp YyBhbmQgbWlzc2luZyBhY2sncyAsIHRoYXQgaXMgY2VydGFpbmx5IHJlYXNvbiB0byB1cGRhdGUg dGhlIERBTyBwYXJlbnQgc2V0IGFuZCBzZW5kIHVwZGF0ZWQgaW5mbyB0byB0aGUgcm9vdC4gQnV0 LCBvZiBjb3Vyc2UsIHRoaXMgY2Fubm90IGJlIGd1YXJhbnRlZWQgaW4gYWxsIG5ldHdvcmtzLg0K DQpUaGUgcmVsaWFibGUgZGV0ZWN0aW9uIG9mIGJyb2tlbiBkb3dud2FyZCBwYXRocyBjYW4gb25s eSBiZSBkb25lIGJ5IHRoZSB1cHN0cmVhbSBub2RlLiBTbyBpdCB3b3VsZCBiZSBuaWNlIGlmIHRo ZXJlIHdhcyBhIHdheSBmb3IgYW4gdXBzdHJlYW0gbm9kZSB0byBpbml0aWF0ZSByb3V0ZSByZXBh aXIgZm9yIGEgc2luZ2xlIGRvd253YXJkIHBhdGggcmF0aGVyIHRoYW4gdGhlIGVudGlyZSBuZXR3 b3JrLiANCg0KDQotUmVnYXJkcywgSm9zZXBoDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpIaSBldmVy eW9uZSwNCg0KSGFwcHkgTmV3IFllYXIhIA0KDQpJIGFtIHRyeWluZyB0byB1bmRlcnN0YW5kIGhv dyBSUEwgZGVhbHMgd2l0aCBicm9rZW4gbGlua3MgaW4gbm9uLXN0b3JpbmcgbW9kZSBzbyBJIHdh bnRlZCB0byBydW4gc2V2ZXJhbCBzY2VuYXJpb3MgYnkgdGhlIGdyb3VwLiAgV2hlbiBhIHBhY2tl dCBpcyB0cmFuc21pdHRlZCBkb3duc3RyZWFtIGFuZCByZWFjaGVzIGEgYnJva2VuIGxpbmssIGUu Zy4sIGZyb20gbm9kZSBBIHRvIG5vZGUgQiwgIGFuZCB0aGUgdHJhbnNtaXR0aW5nIG5vZGUgKG5v ZGUgQSkgZG9lc24ndCBnZXQgYSBsaW5rIGxheWVyIGFjayBmcm9tIHRoZSBkb3duc3RyZWFtIG5l eHQgaG9wIChub2RlIEIpIGFmdGVyIHNlbmRpbmcgc2V2ZXJhbCByZXRyYW5zbWlzc2lvbnMsIGl0 IGNhbiBzZW5kIGFuIElDTVAgZGVzdGluYXRpb24gdW5yZWFjaGFibGUgcGFja2V0IHRvIHRoZSBy b290LiAgVGhlIHJvb3QgY2FuIHRoZW4gdHJ5IHRvIHVzZSBvdGhlciByb3V0ZXMgaXQgaGFzIHRv IHRoZSBkZXN0aW5hdGlvbiBvciBpZiBpdCBkb2Vzbid0IGtub3cgb2YgYW55IG90aGVyIG9uZXMs IGl0IGNhbjoNCiANCg0KMS4gICAgICAgIEluY3JlbWVudCBpdHMgRFRTTiwgdHJpZ2dlcmluZyBh bGwgbm9kZXMgaW4gdGhlIERPREFHIHRvIHNlbmQgaXQgYSBEQU8sIGF0IHdoaWNoIHBvaW50IHRo ZSBkb3duc3RyZWFtIG5vZGUgYWRqYWNlbnQgdG8gdGhlIGJyb2tlbiBsaW5rIChub2RlIEIpIHdp bGwgZGV0ZWN0IHRoYXQgdGhlIGxpbmsgdG8gaXRzIHBhcmVudCAobm9kZSBBKSBpcyBicm9rZW4g YW5kIHdpbGwgc2VsZWN0IGEgbmV3IHByZWZlcnJlZCBwYXJlbnQgKGFzc3VtaW5nIGl0IGhhcyBv dGhlciBwb3NzaWJsZSBwYXJlbnRzKSBhbmQgc2VuZCBhIERBTy4NCg0KMi4gICAgICAgV2FpdCBm b3IgdGhlIGRvd25zdHJlYW0gbm9kZSBpbiB0aGUgYnJva2VuIGxpbmsgKG5vZGUgQikgdG8gZGV0 ZWN0IHRoYXQgaXRzIHBhcmVudCAobm9kZSBBKSBpcyBub3QgcmVhY2hhYmxlDQoNCkEuICAgICAg V2hlbiB0aGUgZG93bnN0cmVhbSBub2RlIChOb2RlIEIpIG9ic2VydmVzIHRoYXQgaXQgaGFzbid0 IGdvdHRlbiBhIERJTyBmcm9tIGl0cyBwYXJlbnQgKG5vZGUgQSkgZm9yIGEgd2hpbGUsIGFuZCBp dCB3b3VsZCBzZWxlY3QgYSBuZXcgcHJlZmVycmVkIHBhcmVudCAoYXNzdW1pbmcgaXQgaGFzIG90 aGVyIHBvc3NpYmxlIHBhcmVudHMpIGFuZCBzZW5kIGEgREFPIHRvIHRoZSByb290DQoNCkIuICAg ICAgSWYgdHJhZmZpYyBoYXBwZW5zIHRvIGJlIGZsb3dpbmcgdXBzdHJlYW0sIHRoZSBsYWNrIG9m IHBlci1ob3AvbGluayBsYXllciBhY2tzIHdvdWxkIGluZGljYXRlIHRoZSB1cHN0cmVhbSBwYXJl bnQgKG5vZGUgQSkgaXMgbm8gbG9uZ2VyIHJlYWNoYWJsZSBhbmQgYSBuZXcgcGFyZW50IHdpbGwg YmUgc2VsZWN0ZWQsIGFuZCBhIERBTyB3b3VsZCBiZSBzZW50IHRvIHRoZSByb290Lg0KDQpBcmUg dGhlc2UgdGhlIG9wdGlvbnMgZm9yIGRldGVjdGluZyBhIGJyb2tlbiBsaW5rIHdoZW4gZm9yd2Fy ZGluZyBhIHBhY2tldCBkb3duc3RyZWFtIGluIG5vbi1zdG9yaW5nIG1vZGU/ICBJcyB0aGVyZSBh IHByZWZlcnJlZCBtZWNoYW5pc20gZm9yIHRoaXM/DQoNCg0KVGhhbmtzIQ0KDQoNCkpvcmpldGEN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1h aWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9yb2xsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From prvs=9820bb3a0=mukul@uwm.edu Fri Jan 7 19:56:14 2011 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 CFEC23A697F for ; Fri, 7 Jan 2011 19:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.403 X-Spam-Level: X-Spam-Status: No, score=-3.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 oSCOJWC-UPNo for ; Fri, 7 Jan 2011 19:56:13 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 8C6993A696B for ; Fri, 7 Jan 2011 19:56:10 -0800 (PST) Received: from mta01.pantherlink.uwm.edu ([129.89.7.132]) by ip1mta.uwm.edu with ESMTP; 07 Jan 2011 21:58:18 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id B6E4EE6A72; Fri, 7 Jan 2011 21:58:17 -0600 (CST) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRviDinXvR4M; Fri, 7 Jan 2011 21:58:17 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 3AE1AE6A71; Fri, 7 Jan 2011 21:58:17 -0600 (CST) Date: Fri, 7 Jan 2011 21:58:16 -0600 (CST) From: Mukul Goyal To: Jorjeta Jetcheva Message-ID: <2136122078.1374298.1294459096260.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A0683D62D@ITR-EXMBXVS-2.itron.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 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] question about broken link detection 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, 08 Jan 2011 03:56:14 -0000 Hi Jorjeta If a node has multiple DAO parents, the root (in non-storing mode) would be able to direct the downward traffic to the node along an alternate route. The problem is when a node has just one DAO parent, the link between the two no longer works and the node does not realize this. In case the problem is considered worth resolving, the node could be prodded from below (ie by a child) to select an alternate parent and regenerate its DAO. Obviously, the node can not be prodded from above (by a parent) since its only parent probably cant talk to it. Also, since the node is going to ignore DIOs from a child, perhaps the prodding could be done by a DIS or a new message to be defined. The child itself could be prodded to prod the node using a unicast message (to be defined) from the root. Ofcourse, the scheme would fail if the node does not have a child. May be in that case a global call for DAOs (by incrementing the DTSN) is in order. Just my thoughts. Thanks Mukul ----- Original Message ----- From: "Jorjeta Jetcheva" To: "Mukul Goyal" Cc: roll@ietf.org Sent: Friday, January 7, 2011 6:19:32 PM Subject: RE: [Roll] question about broken link detection Hi everyone, Thank you for your input. I think that the basic route repair mechanisms should be defined as part of the base RPL protocol. Perhaps this is another item for the re-chartering to-do list. Solving this problem should eliminate the need for proactive neighbor adjacency detection mechanisms. Jorjeta -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu] Sent: Thursday, January 06, 2011 6:03 PM To: Jetcheva, Jorjeta Cc: roll@ietf.org Subject: Re: [Roll] question about broken link detection Hi Jorjeta As Don and Jerry pointed out, the P2P mechanism can be used to discover "on demand" a new route from a source to a destination. But, the P2P mechanism does not repair an existing DAG. It creates a brand new temporary DAG for the purpose of propagating the discovery message. Thanks Mukul ----- Original Message ----- From: "Jorjeta Jetcheva" To: roll@ietf.org Sent: Wednesday, January 5, 2011 5:06:56 PM Subject: Re: [Roll] question about broken link detection So it seems that at the moment there is no efficient way to perform low-latency broken link repair in the absence of upstream traffic? Jorjeta -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Reddy, Joseph Sent: Monday, January 03, 2011 4:11 PM To: roll@ietf.org Subject: Re: [Roll] question about broken link detection Hi Jorjeta, Option 1 will work but at the expense of lot of ( unnecessary ) traffic Option 2 has less overhead but may not work in all networks. The DIO transmissions can be very rare in a static network, so lack of DIO's may not be a practical method to detect broken downward paths. If there is upsteam traffic and missing ack's , that is certainly reason to update the DAO parent set and send updated info to the root. But, of course, this cannot be guaranteed in all networks. The reliable detection of broken downward paths can only be done by the upstream node. So it would be nice if there was a way for an upstream node to initiate route repair for a single downward path rather than the entire network. -Regards, Joseph ---------------------------------------------------------------------- Hi everyone, Happy New Year! I am trying to understand how RPL deals with broken links in non-storing mode so I wanted to run several scenarios by the group. When a packet is transmitted downstream and reaches a broken link, e.g., from node A to node B, and the transmitting node (node A) doesn't get a link layer ack from the downstream next hop (node B) after sending several retransmissions, it can send an ICMP destination unreachable packet to the root. The root can then try to use other routes it has to the destination or if it doesn't know of any other ones, it can: 1. Increment its DTSN, triggering all nodes in the DODAG to send it a DAO, at which point the downstream node adjacent to the broken link (node B) will detect that the link to its parent (node A) is broken and will select a new preferred parent (assuming it has other possible parents) and send a DAO. 2. Wait for the downstream node in the broken link (node B) to detect that its parent (node A) is not reachable A. When the downstream node (Node B) observes that it hasn't gotten a DIO from its parent (node A) for a while, and it would select a new preferred parent (assuming it has other possible parents) and send a DAO to the root B. If traffic happens to be flowing upstream, the lack of per-hop/link layer acks would indicate the upstream parent (node A) is no longer reachable and a new parent will be selected, and a DAO would be sent to the root. Are these the options for detecting a broken link when forwarding a packet downstream in non-storing mode? Is there a preferred mechanism for this? Thanks! Jorjeta _______________________________________________ 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=9820bb3a0=mukul@uwm.edu Fri Jan 7 20:00:39 2011 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 D113E3A6971 for ; Fri, 7 Jan 2011 20:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 i11L1CLP8teo for ; Fri, 7 Jan 2011 20:00:38 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 4E04D3A694F for ; Fri, 7 Jan 2011 20:00:38 -0800 (PST) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 07 Jan 2011 22:02:47 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 001B92B3F06; Fri, 7 Jan 2011 22:00:46 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4W0Y5trEw8V; Fri, 7 Jan 2011 22:00:46 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 456DF2B3F05; Fri, 7 Jan 2011 22:00:46 -0600 (CST) Date: Fri, 7 Jan 2011 22:02:44 -0600 (CST) From: Mukul Goyal To: Jorjeta Jetcheva Message-ID: <419756538.1374349.1294459364440.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2136122078.1374298.1294459096260.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 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] question about broken link detection 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, 08 Jan 2011 04:00:39 -0000 > Ofcourse, the scheme would fail if the node does not have a child. Or if the root can't reach the child without passing through the node first. Thanks Mukul ----- Original Message ----- From: "Mukul Goyal" To: "Jorjeta Jetcheva" Cc: roll@ietf.org Sent: Friday, January 7, 2011 9:58:16 PM Subject: Re: [Roll] question about broken link detection Hi Jorjeta If a node has multiple DAO parents, the root (in non-storing mode) would be able to direct the downward traffic to the node along an alternate route. The problem is when a node has just one DAO parent, the link between the two no longer works and the node does not realize this. In case the problem is considered worth resolving, the node could be prodded from below (ie by a child) to select an alternate parent and regenerate its DAO. Obviously, the node can not be prodded from above (by a parent) since its only parent probably cant talk to it. Also, since the node is going to ignore DIOs from a child, perhaps the prodding could be done by a DIS or a new message to be defined. The child itself could be prodded to prod the node using a unicast message (to be defined) from the root. Ofcourse, the scheme would fail if the node does not have a child. May be in that case a global call for DAOs (by incrementing the DTSN) is in order. Just my thoughts. Thanks Mukul ----- Original Message ----- From: "Jorjeta Jetcheva" To: "Mukul Goyal" Cc: roll@ietf.org Sent: Friday, January 7, 2011 6:19:32 PM Subject: RE: [Roll] question about broken link detection Hi everyone, Thank you for your input. I think that the basic route repair mechanisms should be defined as part of the base RPL protocol. Perhaps this is another item for the re-chartering to-do list. Solving this problem should eliminate the need for proactive neighbor adjacency detection mechanisms. Jorjeta -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu] Sent: Thursday, January 06, 2011 6:03 PM To: Jetcheva, Jorjeta Cc: roll@ietf.org Subject: Re: [Roll] question about broken link detection Hi Jorjeta As Don and Jerry pointed out, the P2P mechanism can be used to discover "on demand" a new route from a source to a destination. But, the P2P mechanism does not repair an existing DAG. It creates a brand new temporary DAG for the purpose of propagating the discovery message. Thanks Mukul ----- Original Message ----- From: "Jorjeta Jetcheva" To: roll@ietf.org Sent: Wednesday, January 5, 2011 5:06:56 PM Subject: Re: [Roll] question about broken link detection So it seems that at the moment there is no efficient way to perform low-latency broken link repair in the absence of upstream traffic? Jorjeta -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Reddy, Joseph Sent: Monday, January 03, 2011 4:11 PM To: roll@ietf.org Subject: Re: [Roll] question about broken link detection Hi Jorjeta, Option 1 will work but at the expense of lot of ( unnecessary ) traffic Option 2 has less overhead but may not work in all networks. The DIO transmissions can be very rare in a static network, so lack of DIO's may not be a practical method to detect broken downward paths. If there is upsteam traffic and missing ack's , that is certainly reason to update the DAO parent set and send updated info to the root. But, of course, this cannot be guaranteed in all networks. The reliable detection of broken downward paths can only be done by the upstream node. So it would be nice if there was a way for an upstream node to initiate route repair for a single downward path rather than the entire network. -Regards, Joseph ---------------------------------------------------------------------- Hi everyone, Happy New Year! I am trying to understand how RPL deals with broken links in non-storing mode so I wanted to run several scenarios by the group. When a packet is transmitted downstream and reaches a broken link, e.g., from node A to node B, and the transmitting node (node A) doesn't get a link layer ack from the downstream next hop (node B) after sending several retransmissions, it can send an ICMP destination unreachable packet to the root. The root can then try to use other routes it has to the destination or if it doesn't know of any other ones, it can: 1. Increment its DTSN, triggering all nodes in the DODAG to send it a DAO, at which point the downstream node adjacent to the broken link (node B) will detect that the link to its parent (node A) is broken and will select a new preferred parent (assuming it has other possible parents) and send a DAO. 2. Wait for the downstream node in the broken link (node B) to detect that its parent (node A) is not reachable A. When the downstream node (Node B) observes that it hasn't gotten a DIO from its parent (node A) for a while, and it would select a new preferred parent (assuming it has other possible parents) and send a DAO to the root B. If traffic happens to be flowing upstream, the lack of per-hop/link layer acks would indicate the upstream parent (node A) is no longer reachable and a new parent will be selected, and a DAO would be sent to the root. Are these the options for detecting a broken link when forwarding a packet downstream in non-storing mode? Is there a preferred mechanism for this? Thanks! Jorjeta _______________________________________________ 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 m.pouillot@watteco.com Mon Jan 10 00:07:16 2011 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 AFBD728C0DF for ; Mon, 10 Jan 2011 00:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.239 X-Spam-Level: X-Spam-Status: No, score=-0.239 tagged_above=-999 required=5 tests=[AWL=-2.010, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sbltpu6MmW6u for ; Mon, 10 Jan 2011 00:07:11 -0800 (PST) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id BE19228C0D8 for ; Mon, 10 Jan 2011 00:07:10 -0800 (PST) Received: from [192.168.4.247] ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id TJT07818 for ; Mon, 10 Jan 2011 09:09:18 +0100 Message-ID: <4D2ABEAD.7@watteco.com> Date: Mon, 10 Jan 2011 09:09:17 +0100 From: Mathieu Pouillot User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: roll@ietf.org Content-Type: multipart/alternative; boundary="------------040303070607020905040800" Subject: [Roll] DAO No-Path in a storing mode 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: Mon, 10 Jan 2011 08:07:16 -0000 This is a multi-part message in MIME format. --------------040303070607020905040800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello , In the specification, for storing mode, it is specified that a device should send a DAO no-path to a node which is removed from the DAO parent set (9.8.4). For me a node is removed from the DAO parent set if it is unreachable on link-local and so I can't send a DAO no-path to this node. A solution to inform the old DAO parent should be to send the No-path on the global address but it is not allowed by the specification (9.1.4-in storing mode DAO message MUST be link-local-). So only the lifetime will remove the route from the old DAO parent, that can take few minutes depends of the DAO lifetime setting. What do you think about that? best regards, Mathieu -- *Mathieu POUILLOT * R&D Engineer m.pouillot@watteco.com *Direct line* : +33(0)4 98 01 60 05 *Tel* : +33(0)4 98 01 60 05 *Fax* : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE -- France www.watteco.com /Before printing think about*environment *and *costs*/ This Message may contain confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you received this message by mistake, please notify the sender by reply email immediately. Please conduct your own virus checks before opening any attachment as Watteco does not guarantee the integrity of this email or attached files has been maintained nor this communication is free of viruses, interceptions or interference. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Watteco. Watteco shall not be responsible nor liable for the improper and incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. --------------040303070607020905040800 Content-Type: multipart/related; boundary="------------050800050905010808050705" --------------050800050905010808050705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello ,

In the specification, for storing mode, it is specified that a device should send a DAO no-path to a node which is removed from the DAO parent set (9.8.4). For me a node is removed from the DAO parent set if it is unreachable on link-local and so I can't send a DAO no-path to this node. A solution to inform the old DAO parent should be to send the No-path on the global address but it is not allowed by the specification  (9.1.4-in storing mode DAO message MUST be link-local-). So only the lifetime will remove the route from the old DAO parent, that can take few minutes depends of the DAO lifetime setting.
What do you think about that?

best regards,

Mathieu

--
Signature 3

Mathieu POUILLOT
R&D Engineer

m.pouillot@watteco.com

Direct line : +33(0)4 98 01 60 05

Tel : +33(0)4 98 01 60 05
Fax : +33(0)4 94 14 10 80

1766 Chemin de la Planquette
83130 LA GARDE – France
www.watteco.com
Before printing think about environment and costs

This Message may contain confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you received this message by mistake, please notify the sender by reply email immediately. Please conduct your own virus checks before opening any attachment as Watteco does not guarantee the integrity of this email or attached files has been maintained nor this communication is free of viruses, interceptions or interference. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Watteco. Watteco shall not be responsible nor liable for the improper and incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system.


--------------050800050905010808050705 Content-Type: image/jpeg; name="Watteco-basemail.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Watteco-basemail.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAWgAA/+4AJkFkb2JlAGTAAAAA AQMAFQQDBgoNAAAIRwAADmgAABSuAAAdtP/bAIQAAQEBAQEBAQEBAQIBAQECAgIBAQICAgIC AgICAgMCAwMDAwIDAwQEBAQEAwUFBQUFBQcHBwcHCAgICAgICAgICAEBAQECAgIFAwMFBwUE BQcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI/8IA EQgAoAD8AwERAAIRAQMRAf/EAO0AAQACAgMBAQAAAAAAAAAAAAACAwEEBQYHCAkBAQABBQEB AAAAAAAAAAAAAAABAgMEBgcFCBAAAQQCAQQDAAICAwAAAAAAAAERAgMEBQYQQBIVMCETIAdQ FnCAMREAAgEBBQMIBQoEBgMAAAAAAQIDBAARIRIFMVETQEHRIjKTFDQQYXFCBiCBkaGxUpIj MzVygkNTcPCi0nMkg5QVEgABAwMDAwUAAAAAAAAAAAABABEyEECRICECMVESUHCQYXETAQAC AQIEBQQDAQEBAQAAAAEAESExYRBBUXEgMECBkaGx0fHwweFQYHCA/9oADAMBAAIRAxEAAAH9 QuIVAAAAAAD27rrnvZjoQhum4bSdymNk2obCNiF5ZCwuhIyfMvz5IAAAAAGD6G7jHLek83Jm 4bJsTOxEbBaWlpMkCwA+auAyAMHmGwVcZ6E+javTzuPAAE630f3iFbzU2zbNg2Zm6I2i4sLC RIyTAPnHg8gdazJ+Ue53tXb7lNin27ULPsvCqOQoADnvae4dejjzoxtm0bJsFxeXFhaTBIkA fPPDpHG3XUOtT8kdByPSMKn6K8i1y+o07XMVoAPRN5j0LeHXTrxtmyXpvReXFpYWEwTMgHgP FZHEbe+jN7j4TzK/qbGp4HDjieOTbUAEqntnW45DNdKNc2i82Jm2I2C0uJkyQJmQDwvjgdI2 SeX2R9De3HmuO6xr87eiQAB2nY3pfQGmdOLjaLi8sLi4sLCRIEzIB4pyWQOt7M7DsceM6TOp YctjLTZPTrS+89Z6XG7lusGiWmwWpuRcWFpMmWAEzIB49y0NWp1O5OjecRbddtuxY7hbiMvc 7bv+6x2bYGkdZLS0uLU2IuLSZYSJAmZAB5RzaR1mt5/QkadTJydtuQxW939+O47UgdaIFhYW lpMsLCwkWAEzIAPMufAAAAOw+47XshLgzVLCZMmXEyRMmSJgFgAB55o4AACdTsvvub9dg4k0 yZMmSJFpYSJEiRkAsAAOjaeAAzLk/Qc97K+8icYa5IkSJEiRItJEiQMzMogZAAOoauGZbF9v Zjks9ddCk48iZJEjJIySMkiZMAmZAAANawnUtuMyArNUpMmTJIyZMmTJkySJAFgAAAAMESsq IAyDJIGTJkGTJkyACwAAAGsYMAGQDIMgGTJkGQADJkkAAACgAyAAZAMgAAEjIBkAAAAFYAAB kAAGTIMgAAAAAAAAAAAAAAAAAAAAAAA//9oACAEBAAEFAvW689brz1uvPW689brz1uvPW689 brz1uvPW689brz1uvPW689brzWaLSzwPQaIv0+oS9NRqSOo1RHU6sTV6wTWa4TXa8TAwRMLD ExMUTHxz8aT86zwiMnRhhhhhhhhhhhhumDHwwyxXuQQTonVPgYYYYX6S7mHH65JzbVvrtlr9 tQwwwwxGCylFPGKqyf8AoiCCdEE+JhhjbbTD0uFscvN3sn+v0tlfxvim0zqMS9MvEYYYY1lP 65xlS8aEQRCPRBhPiYYzMqjBxd5wrL2nHY32ZScg4vteLXf1Vp44+n3PIv8AYqoVwrgwwwxo 6OmfL6RBBBhPkYYx8b2nI4W1XH9S8d/Hacw43Dlei5n46zhcKoVQYYYYSKquLSmPQZE/0uYQ TonyMMfryHV7D+v8NNPkNj4lfE+Uw5Ph8ks9jvmGGGGNVjfpcXz/ADrYRBOiDCfGwwxTP1/K +cZflhb/AGuFqNhqeQ4CXw5bVZhw5frrEyOU4mII0khXKyWPTHHqMmfnNhBE6IJ0T4mGLbqM eO09bsMPBitmdutTxje2Yen4dZfRgaKOLZo9Hjl+i0ObbGCRTX4n5IX2fnFhuiDfMwxttRib nFq4Lp6sjE4PrMLG/wBC1sYLwPXSWHEKIrPi1U7cTiOuwjCxPJRVSKTks5MMMJ87DDDDDDDD GNhv1ts81YbsmGGGGGGEgsloxIw622eQw38U+ZhhhhhivElIhXCtBVYnNZDDDdmwx4uJRYpH FI1wh1lNEFVZDDdr+VZ4QT+KyRBZqo3d+SHmKqr1buPs++jdGG71hhhvkbu2/wAn/9oACAEC AAEFAvYXnsLz2F57C89heewvPYXnsLz2F57C89heewvPYXnsLzX3TWn9JH6SP0kfpI/RTzU8 1PJTyU8lHHH7PDi1XbU6q+ZLQ5KFlMoL/GMXVEbtaMeVktfp66ek5pE2FULyUWX+Gvq8reyY YhWslwcZKCdjJTkeS3zeWZsI1jDDDDGnq7NhjU0/ZZY6RVi6fjFEGGGGGMerwh2TDGHmpVDA uWcCu2M02lrQYYYYY12O8uzYYY1cmllXeEMWcqy+SyXx+/AjFxCMHWmrwj2bDHiR8orffOxU SSE65i1TPGRGuRGDGFjePasMJ9C+RJ1V1HUYSJ9mJi9swwwwwwwwxj4vbsMMMMMMJFynGbuG GGGGGIYyqQgidywwwlKkcYjBE7v80PBP+P8A/9oACAEDAAEFAnHHHHHHHHHHHHHHHHHH/wAo 3fInVV75FF75V/7uf//aAAgBAgIGPwKRypHKkcqRypHKkcqRypHKkcqRypHKkcqRypHKDn0A flvtxXRNyvPHin68qsdQtWC+09WEtR5WvlQUJ1tasnPWmy8e+p+1uQnThHkU2hk1u4W9GT6H N+5v3N/vfb+/X//aAAgBAwIGPwL4gP/aAAgBAQEGPwLyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W 8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3Sd FqZpNHpXdhixp4idvst+y0n/AK0P+20oGlUwAOA4EXRb9rp+5j6LftlP3MfRb9tp+5j6Lft0 HdR9Fv2+Huk6LeRh7tOi3k4u7Tot5SP8C28tH+BbfoJ+EW/SX6BbsD6Bbsi2zkFKu5F+z0SH ex+3khYm5VxZuYCzJDVtqTpgwpIpKhb/AONBk/1W/MoK+FP7nhc4+iFnP1W8VptYlZADldkO Kt91gcVPqPylUbWN302VRsWxO61/I3rqwnICFhgQZpJpW7MaDnY2z6ww8Pth0VDfTR/x/wB1 vWcNwsFGCr2V3WSmpqaavq3VpBSU8TTScJO05C7FF/8Ak2qfi6nqzopMDjTIjEL65FGYNUrI L+HeOoMG578brUlWFyCqijlCbuIge76/kwDmQ5j/AC+iT14fTyOesqTlhpxe9wvY8wAHOScA LVms6gXT4looZKjQqGORuFSMFz8IhcJGkAySM1+3q3WoE02nNdWaw0aaTRg3cR5Vzi88yqvW Y8wFtLFdWx6jT6sGQVEcJhENUi8Th4s16st5U7cLVPxLOt1X8SNnhY7UoIb1gX2ML5P5rT6P 8PMW0+ozRap8Rj9IRnqulMf6jnZnHVXeThZI41yRxgLGm4AXAfJmqDz9VftPoRN+J5Hp1Gwz Umjr4+sHMZsxiplPzh39qi0gjkWXhsUluIOVhtBu57a5WVKXj4WmqdI0y/mZJyZHH/j4Sg+2 1TpHifBTOUekrguYwyI1+YD2Xj57Vun0KCPxMUOm6fFu8Uy0S3ewPfZIolyRxgLGgwAUYAfJ AGJOwWji+6Ot7fQx5hgOR6rLo9FTVQ1hIAlbPMyeFeFWTrRqhMi43gAjHdtt8S6LxmqX40Ff JVSfqTPWw5ZZG9bSwsbTS3LTxDNJUPcFG9mNnlkon0uuiytLp0hDNwZuvDKCNqyLj6jeOa2k 6YvWg0YGurv+V1aCnX63b5h8rjN2Idn8XoJ5z2eS6VWHCDWIZaCc83FX/tQfZIPntS/D0Lf9 v4mkMDXbVo0Gepf8HV9rC2nzRVjaTq9I1NFSTiLiwyQ1sjRcORAy5ogY72xGW68Wigzz6nq/ xCsta1Tw0jEzKTGii9rkvSI8JSeyu22nVyaNVtDqswgpPK352JAv/Owvym1UUglZqep8JHCp gaWWo4rQ5VRZLxipxe4XY2qPE0VQn/z4km1i7hMKSOQsAXyvjgpbq34WvGI32VFF7NsssS82 07z6Mo2JyTPPMsCY9Z2CjAZjt9Vp6WTUUp3Q5o6lZEEkE0Dq6ut/OjZbT6vq2qQahqnDWnWW MCKKGFXHVVC73ZnN7G/E3bhaKXUalGkanqKWFlnC/l1ShWuu977p5rUtfR1SGqppKPwVVxBn Tw9OqRRqW90o2I57zbStPi1JWj06oD0K8ZCxmjJa47+3avp5tceE8bxeQzQI9LO0xmDoQgbt P71+26zU9RrzzzVsccGpwiphBrUViyLKEUffu6t2ButcLcZx+Y3ZG4ejDtHZyUUdYCYQ6uQp uvy8x9RGBtQ1OeaR6BYVUM94k4WbF8MS94Lb7haupIaio4eoRCKpJcFrgrC8G7A3tffvAtDH DWVEMcMvFCZ1IJzxuO0vNwh9douJWTyiIKuVjEQUVY0u7HOIVxtDm1KokWJYoyh4VzQQOkkc ZuQdkoMdpsZxqVQknF8RERwepUFQjPjH7wGw4WiWCSUJD2FLA/1IZd2+AWE0g6vuLv8AQSdg tmPzDlgklHV91N/puHZHK7lF53WzSdZuYcw9OUdnld79QfXa5Rd6Lza73eUYW7N1us3zC3VW 707zbHk/Zt2R8rdy3Z/g5//aAAgBAQMBPyHzhQoUKFChQoUKFChQq6IF6Zarw+F9tAAPjhT8 HhcxNpGBqhiBoUgNDgBoP8+kAYD+HSC0L+fSBaF/LpAtDgDoXsSjk88ABU6+2ve3gqBywwOA IcBDygodEUNA1VdCOiBAIcpge6jZHVjy/RZI8owXoj4gaCSHuqDpAA9ipd+gX4hlbVb4BxwH EOXE4GvjDm+iwTZlnTkFqgLFmYWUJk5a+eG6WqIxAoMAOQcoE/WY09NgW6qBaqY28UxOQ0FS XUQzESC65Bt4QYg+w1/euFm5in0cBOAghwDlwNeIc/B2TsiIMrWZRsrAtVCB9bKzrJXYDIoy 9A0bD1tQ08p2lqbsmfSuLCZb1Jjz49KHXohd9sYfTBLpNo73JRgUoIaVw2AnZOydk7JUA5H7 f4cMf5qO2DgCGHAIEDSGsOJp4jGAvNLsBJGKMjWo1aheRmQyeOYM6gDZzinVehsLBd2dlLbg D0R0f5BCoDkAtANADHhAE7FdRYL9czqsv14cwvjSECCBwBCHKVDiaeI1QGk+FBF4mwoYzLSI QtRi1wwXRiOFsZYVdlZxasqquyLqUwOjAuVDT9QZczeqfK7meIGDPuFp8a8KX6Xcw6uAMQII cA5cTiaeMXdzIUHsfY+4irwJr6IemznVeTZZngMiDa3yDGWES7rQza1J0QWHUZwLJtnlNdyr q7C9VFTKoTkog7TKZoXhtlQtmg0lhY0ZlM+cavDPnK9+cIExQIIIHAHl+sFGIHyM0Cu0oFS7 jSSD1krQcMVXsx9jNkU8DAEsD6+lCzQd0tazCinGsWD37XZZQjrk7MdWncl0KNaLGBwAjWCm WeuSLkdhYW3LEgoKCchTk/lbw1VyfzhBAQwgIQOIeUWoq4cl4nOR5jNEWhe2HVGebpywmw/A vvol8CCyULTLUlDArkjnEW/lhu+4RnDVXLY+vNqJgWq6lryMi68wNxrwGwW0GKBqx5CZq/gb 9tEJlubq7cHDrUjv8AQgg4FSoQh6MAactX9jhpljdot94QQECBAxAgcT0H89d9BKWrignzT1 4gQJUrgCVwCVXk9s7Z2ztnbC7QWuhKLsMd4M83gAsoJjWOjrxOyVKJUqEOFeCvJBaF+0++ji DrdDSDdz44H2I5a7E7OCpUqVKgVwIeCvI28NJ8RADQrwak56TFGHBUqVKlSuFSuJ56HOPRHM pUrgqVKZUqUcaZXnX1zulcFcSpXhqVK8dSvJqVK8IVK8muCvR0ymUymUymVwUSj/AKP/2gAI AQIDAT8h/bvzP278z9u/M/bvzP278z9u/M/bvzP278z9u/M/bvzP278z9u/M/bvzP278xZRa 6zeZvM3mbjN1m/N2b03uBeXlpcvjUqVKlSpUqVKlSpUqUfZ6KpUqVKhdpW+PvALo+5KiUypU qVKmE6ytXoqlSoHC1gNu5+OGrQKrTnzlgdJUqVKnYWfj0oA1GZg7n+coEzUPAiHJ9nf8eIH2 T0oC1yxwqnQiqybKkx+EBrRK7p9KJEK3c6vTwuDvlKAa/YeIGb6fd6cbo5l3zcu8e1DNnb++ k5fOO3657xIrGO/4iiu1+0DQ66byjHqasMj6YEys1SAqUGhCMdb+IM6M/WWHqILT7d4AutNM adpQqVOc+nG6IkJ1lIvLh/z/AJ3ioNV7e013/Of5lnS9eALej64A6og56vXA9IQXHqwvG8oH OaB6vbgHKV/8+//aAAgBAwMBPyG0tLS0tLS0tLS0tLS0tLS0tLS0tly5cuXL/wCZTL+trirX rYYsvjt9eD/3z/8ATn//2gAMAwEAAhEDEQAAECSSSSSSZWyQojzwhEkkkkklqFAIABIIAP8A 9xL/AP8AVMBxAIIAANtPvnttAlI2AIAAAG7GFu23xgAgIBAAANkOCNthBhIYIJAAAG5lU222 BoG4BBAAAAAqTyQAMAMJAAAIAPztE74QtIMBAABAAJI3RDSIpI3JJABAALbbbadEAAwIIAAA ACSSS+JpIOABJAIAAP8A/kgRASBgAQCiAABt8AAAQSOCSATgAACZAATSSAiSQAQAAAACBAQS CkACQAQAAAAASAQQCQCAAcgAAACSAAQSAAAQCQAAAAAASSAASAQAAAAAAAAAAAAAAAAAAAAA AAD/2gAIAQEDAT8Q87Dhw4cOHDhw4cOHDhU3lwqwprjq8GRxgjgNUAhD1QZkAUG/sQEwEwRS 7dafihHzm4wWlHLR7YX2i6wWlFIT2QZO+CGPodH9oaPZi/qfQgL+oaYOwSiqrHSWlpaWlpaW lpaWlpaWjUXpHWKTG4v78A5Gu/dDpuwlYwOn8uHjeGw2/M16YESiic00E0+/A1O/gttLbS20 ttKw9lEbpgBlVoiz8lyUpJTmaOc+ytXYCGzdorNSFEoNRtK9JbaW2ltpbaW2gJWL7gfvDioP 2IfaHgCjsLmbkUndzNKnSPTnRMaJy9py9pzT+qGpw0+/DS8FZWVgpqsKFTRDRQAyMNRr6NEd K7oESp0IBBVAMA5BHCaYlIDJU5SYE+RpG2mGQA2AiRc9NgIqF6V86lZWVlZYVmWFgUb+DhnO u7Vf1YOKxAb0QYTcgyQEtIxpmc0/qhqd5ocdK3t4qRLV1VHMdhBjLC4L616GyQAQkB0BJbK0 Lj0VNQTH2HSl0fThMuIjYN2DZXAJql6KLNc9S1dXlL0gyREUaLEcgA2PDVYsbbFRPlHtwyNl tsPuL8Q3AxsPXNwlBNZoVyhaCu852XUPIicmCZCa+Ol4uyNYRaxRMFDkuDkdg2ASpDhIJZmL VfBJR568iAJpQkQ7lEC84LJEDnsOq1C86K8oQn3oc3AMAKDB4fUCMLKigO6ykNJTu/3TwIHI u5aNndtj4QvaYgTkBcpbNIxeJq9pdsHKHFw6PmAMhNLx0vBfaX2lE10hzq5lXjAKKUuAySUH AlQASzfMreBQoWWatZW0Q+opgUGiLzAQosAscLqVZURfaX2l9pfaX2ipZpbmCfY+VcL6UH0q /bWaVO6xCkyay8dTnFKxLguYLMXOaZU7Q1O/DTx0vB2v1na/Wdr9YVh44Y2XGeoDGWpR5Ukd dho3vFE5xc2mBgslKPJaQNmXtTPOYy3VIwjoH8+wVE4vgNmqVKDMXo+5WAsZbT3TF1cAyRYK I5bZaHIiajHJm7167GrtMAoXTTlJ3fpwbMrx0ed7aQnCSnFY6zAr4iYsiaddJ1OU0XQ6QasS xrHhNDwdk7JiOGadCgrNWArgmOGNblCMLWQtKj4kZYqNvanpb+EkLDXsWLOtJZ2atGzEYDxZ DGO7VZIZlVshdI6W6WNa+XiVO3HUl/8AKNP7gKVGEnKKICg7BoTQRSNlc/k6GOvCxKL+qdfZ Lc83Xmyzv0l+E95QprLPfSVOSq0hujTEJtYBoc4Gge0QRTiaHj7DWBCwrJzXUWXcGBKDoa3I yLajFLGrPJ6NhiKhsQhym8VuPSiEuNQtTCBXKtaECok5YRxSCxVAK4GQhBNwH+0vVkx0Gsc8 SnFi4LnUeYxrn4FoZC6ORz4VtBamBccWaGh+YB2lFdOcCh0uDPeFIHF6w4uafeafeGp38Boe G8vLy8vLy8vLxnSFJ16EuhtzgAAFBoRQKUGVdAly0XDr6v6mCtJg6R6x8yjv1iaxEUSgrmxL tKrgFFfMFp4Dw9s7Z2ztnbO2dsYpoRb/AIbxwwadVPfV34KAq0GVeUUbQfy7QyhV0reZcazL nO0L8oHnDZX80lG6wS6VvKOkBLYDRz4haHi/hmfwzP4Zn8Mz+GYpP0QKvsS1FnevbQ9/iUpB 3+4uXgn5gMufuzu/EO5howENEX5uJtQ9sCbw5sMTneFd+NbQHSUdPF3zvj1K+gn7SjqjZ/19 IeldQUfL+IDTHOtruueNuOx5d2Zkq0NDtwjAzW0DjEvzZWHQQbridwwF0IUu5r4mpAHkBf7P 3Zp2kBQDoFeDnp0MsBRV6avvDLSt2X6yu8C6Fwfad8Cbyqg0uBrOWAGkp6Qoq44mp38tQytE 6lehn7TrTu/5MM0Ohj7QfSped0DzzAGhNiXnfNqaYJrgm1K9YFFeA1O/k7z5jfVPvFupcttL zczulesCbyjpxp6S8OtgTeUGh4aYNgxHyby8vO6d07p3SvWBN5R0lHTxVekt0ndAmuZR0lHT zqekp6Mp6M2JsTam1Nqe1L9Z3TamxKrT/of/2gAIAQIDAT8Q879+/fv379+/fv379+drLKpX Lqrc/fMf9Zn7Jn7ph/rMeq+Wbz5Zvvlm6+ZvPzN9+Zus3JeWl+f/AP2Ns/sXweJH0Px1o50H 2T2YgzHzT5JT4voR1QfLUIToAfHB4kfMvLy8+0AXVegc2DROcjTs5G+sqGC6uCLBoGA7PTZw xdRsnw1Ly8vLxj8lb6vvXAjxPPAKtqDeHmV1ubHT7tWXZpy3iMweVS2eRgiFnSNN245autEt z18IVi88Pu/1wPAeebY13dX4x78H7qd/1BeoQnOc/Bj6yjd4QMBa4IA2oz3cv14cvBfn908h VU2GFvFV0cRgli7oXkDYGjtAuKKgVdxp/wA6mZzwOfkflo+fF/F3S35PjX44EeJ6H2BoQdzD 9H6SptWO5g+NfaYBoWHWg+2XdkjpAIpnCjTFokt1R7XG3Z+xHLIXkpooNrVOpgtvEp6ck1Fi tMY1DNZxKtkP5UonKo1erzeB4D0G5guIC0kxh1w7JcXOXi3PNvnjToe8ogcDRz0e3U5xCrEW Kw2VXcTDyojna1OOT9tJRgOORQBVOa0OVZLlGEEqtlotna83SXAraTC2LGx+XgEfSaV4tV/N zU3lpKLe11p0qsdLesakW7Ppvpiuyy1VRUrn0Trzv7QEaovvra3ru2i7wF289URdeY6aHIgr ASurNrDXl116stXP8of2+kvh4aHXd26dfIv0/wDr4Ww699toFcDHqwFMbZXZ+jkfl416r41o 1mWwfX/JTjX34nifRS6C50d3nMfiH415T5N+RtpoQ+IA08V+sr/o1/6v/9oACAEDAwE/ENyb k3JuTcm5Nybk3JuTcm5NybkepNybk3JuQ60XLy0tLS0tly/BiYmJiYmJiYmJiYmJiYj4SPmX Lly+A0YOJcuXLly/ER88SwTgOqAvifEEfPrYYXLVcMDxPiPPeFwEobh5t+geCQ8T4j0LpwVK lSvKI+iuXwvySaeguXLly5cuXHx1L9dXqL/5D5FenfJv/wA7UT0l+Xf/AIv/2Q== --------------050800050905010808050705 Content-Type: image/gif; name="sig-ecolo.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="sig-ecolo.gif" R0lGODlhGAAXANUiADamKSuhHonKgla0TG29ZEmuPiGbEyliIC+HJBp9DZ+inEGqNYLGel22 Ury/uWW5W3+DfODW4NDK0sS7xU2wQmSPXaTVnZDNiN3v2pzSlpTPjbfespjQkXnCcMLjvlKx RsnmxbLcrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAACIALAAA AAAYABcAAAb/QM9gSCwajwNMwxBoOgOA6BPwDBgYBGh0a0gkDNvwNiDIig+QyQRy0IqpZTfg IBHZRZLDWxrnKu53Dl9vZGYBXg6AdhgKCghyhVAHEw51incHFFR8WQZ/l4AQBgMMD1AGcQGf oCIRCVQBBA1NqRWsdwpgAFdwZgiJtxF6VA8UqGYACROKDhF2wlIEBccBCwmrdhKrEK9UDLS+ l6vCCwIMs3CmAAi2dwwHFhJs1RYFGwK7fbvsFQgJbf52NbiQAUDBSFEWwEJwAEFCAxc0yBIw C6EYhggURqHA4UEfi2EONAwToIOFD1pAhnkkxskYAQ/AQJk5ZpNNLVdCFNjJs+dOBwo+eS4A EQQAOw== --------------050800050905010808050705-- --------------040303070607020905040800-- From mcr@sandelman.ca Mon Jan 10 09:45:55 2011 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 C625228C110 for ; Mon, 10 Jan 2011 09:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 wB9avOd+r7cp for ; Mon, 10 Jan 2011 09:45:55 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id D90E528C10E for ; Mon, 10 Jan 2011 09:45:54 -0800 (PST) Received: from marajade.sandelman.ca (fw.acmepacket.com [216.41.24.2]) by relay.sandelman.ca (Postfix) with ESMTPS id 48DB7341B1; Mon, 10 Jan 2011 12:56:59 -0500 (EST) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id B4EF0985F3; Mon, 10 Jan 2011 12:11:48 -0500 (EST) From: Michael Richardson To: roll@ietf.org, Mukul Goyal In-Reply-To: <2136122078.1374298.1294459096260.JavaMail.root@mail02.pantherlink.uwm.edu> References: <2136122078.1374298.1294459096260.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 10 Jan 2011 12:11:48 -0500 Message-ID: <32131.1294679508@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Jorjeta Jetcheva Subject: Re: [Roll] question about broken link detection 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 Jan 2011 17:45:55 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mukul" =3D=3D Mukul Goyal writes: Mukul> If a node has multiple DAO parents, the root (in non-storing Mukul> mode) would be able to direct the downward traffic to the Mukul> node along an alternate route. The problem is when a node has Mukul> just one DAO parent, the link between the two no longer works Mukul> and the node does not realize this.=20=20 Assuming that the root knows that the origin path is broken. Is it acceptable for the root to round-robin among paths that are otherwise equal? Mukul> In case the problem is considered worth resolving, the node Mukul> could be prodded from below (ie by a child) to select an Mukul> alternate parent and regenerate its DAO. Obviously, the node Mukul> can not be prodded from above (by a parent) since its only Mukul> parent probably cant talk to it. Also, since the node is Mukul> going to ignore DIOs from a child, perhaps the prodding could Mukul> be done by a DIS or a new message to be defined. The child Mukul> itself could be prodded to prod the node using a unicast Mukul> message (to be defined) from the root.=20 I think I get you, but this is one of those cases where an animated slide helps a lot... My reading of: Mukul> As Don and Jerry pointed out, the P2P mechanism can be used Mukul> to discover "on demand" a new route from a source to a Mukul> destination. But, the P2P mechanism does not repair an Mukul> existing DAG. It creates a brand new temporary DAG for the Mukul> purpose of propagating the discovery message.=20 is that essentially if there is a child who expects to receive unidirectional traffic on a sporadic basis, that it needs to create a new DAG, the "how-to-reach-node-X" DAG. While one might think that arrays of sensors (P2MP) systems would be mostly poll by central systems, based upon my understanding of CORE, that the sensor can come up and asynchronously transit data to a gateway. In that application state, I think this isn't a problem. In the "where the light bulb I'm trying to control" problem, I think that there is a real problem, and I don't think the "how-to-reach-light-bulb-X" DAG scales very well. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATSs904CLcPvd0N1lAQJbAQgAiF4Ebp2Gpef2okovOxYzaOw4fplnJ801 NmCpeZ5iN1SY65Dui3K3ArKMNufS6tivZkEDjlK5eLWsR07PoYyJO+kPME/2mhWE BBCA5/09xJFUx1LzNVBvqaeJzUs95HNl2t7NqTEReMzfOcOMqw1U5CGEByDb+EXb KsHCJtjUGjDYfrlzSg5+7pHrKQs22DmIMOFwNckyeZSJQkPBnyHKFKPkASOYdr2L VeszrpwNBZzHPx9i5Z66+xoel5aL6Lsr6Mib+Z74/HVK/gu3P/0yCCb0yvUqWlwP oF4KA1eWiDpeWQg7jqI8nwXLR247yqzrP9Di2fmk2k39k7Bp7lvEeA== =xe41 -----END PGP SIGNATURE----- --=-=-=-- From Internet-Drafts@ietf.org Mon Jan 10 10:00:04 2011 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 0960A3A6B0A; Mon, 10 Jan 2011 10:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, 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 dq3uZSRkjUxf; Mon, 10 Jan 2011 10:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C7F3A684C; Mon, 10 Jan 2011 10:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110180002.8969.52208.idtracker@localhost> Date: Mon, 10 Jan 2011 10:00:02 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-trickle-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, 10 Jan 2011 18:00:04 -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 : The Trickle Algorithm Author(s) : P. Levis, et al. Filename : draft-ietf-roll-trickle-08.txt Pages : 13 Date : 2011-01-10 The Trickle algorithm allows nodes in a lossy shared medium (e.g., low power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allows Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-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-trickle-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-10094739.I-D@ietf.org> --NextPart-- From prvs=98465bbf5=mukul@uwm.edu Mon Jan 10 15:28:29 2011 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 D7E193A67F6 for ; Mon, 10 Jan 2011 15:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 VCdFd6DtjrrT for ; Mon, 10 Jan 2011 15:28:28 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 7E1B63A65A6 for ; Mon, 10 Jan 2011 15:28:28 -0800 (PST) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 10 Jan 2011 17:30:44 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 0680B2B3F06; Mon, 10 Jan 2011 17:28:43 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mV4aNT2AIZCU; Mon, 10 Jan 2011 17:28:42 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 85F712B3F07; Mon, 10 Jan 2011 17:28:42 -0600 (CST) Date: Mon, 10 Jan 2011 17:30:42 -0600 (CST) From: Mukul Goyal To: Michael Richardson Message-ID: <1464210115.1428295.1294702242593.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <32131.1294679508@marajade.sandelman.ca> 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 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org, Jorjeta Jetcheva Subject: Re: [Roll] question about broken link detection 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 Jan 2011 23:28:29 -0000 >My reading of: Mukul> As Don and Jerry pointed out, the P2P mechanism can be used Mukul> to discover "on demand" a new route from a source to a Mukul> destination. But, the P2P mechanism does not repair an Mukul> existing DAG. It creates a brand new temporary DAG for the Mukul> purpose of propagating the discovery message.=20 >is that essentially if there is a child who expects to receive >unidirectional traffic on a sporadic basis, that it needs to create a >new DAG, the "how-to-reach-node-X" DAG. You are making the P2P mechanism sound like a proactive mechanism, whereas = it is a reactive mechanism. It discovers routes between two nodes "on deman= d". There is certainly a cost associated with this route discovery (the con= trol messages generated during the temporary DAG formation). This cost can = be controlled/limited by using the propagation constraints to restrict the = scope of route discovery as well as by carefully choosing the trickle param= eters. As mentioned in the Applicability section in the draft, one has to t= ake in account both costs and benefits (routes hopefully better than what a= re available under global DAGs) before using the P2P mechanism. If the two = nodes in question are expected to be nearby, using the P2P mechanism makes = sense and would probably result in better routes (than global DAG based rou= tes). If the nodes are far apart, the discovered direct routes probably won= t be much better than global DAG based routes and hence it does not make se= nse to use the P2P mechanism in such cases. Thanks Mukul >While one might think that arrays of sensors (P2MP) systems would be >mostly poll by central systems, based upon my understanding of CORE, >that the sensor can come up and asynchronously transit data to a >gateway. In that application state, I think this isn't a problem. >In the "where the light bulb I'm trying to control" problem, I think >that there is a real problem, and I don't think the >"how-to-reach-light-bulb-X" DAG scales very well. --=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video =09 then sign the petition.=20 From iesg-secretary@ietf.org Tue Jan 11 08:16:37 2011 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 F270B3A6A58; Tue, 11 Jan 2011 08:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.303 X-Spam-Level: X-Spam-Status: No, score=-102.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, 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 Veza8z9B72sc; Tue, 11 Jan 2011 08:16:36 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC4728C2C9; Tue, 11 Jan 2011 08:16:35 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111161635.23296.53008.idtracker@localhost> Date: Tue, 11 Jan 2011 08:16:35 -0800 Cc: roll mailing list , Internet Architecture Board , roll chair , RFC Editor Subject: [Roll] Protocol Action: 'The Trickle Algorithm' to Proposed Standard (draft-ietf-roll-trickle-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: Tue, 11 Jan 2011 16:16:37 -0000 The IESG has approved the following document: - 'The Trickle Algorithm' (draft-ietf-roll-trickle-08.txt) as a Proposed Standard This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-roll-trickle/ Technical Summary The Trickle algorithm allows nodes in a lossy shared medium (e.g., low power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allows Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. The Trickle algorithm establishes a density-aware local communication primitive with an underlying consistency model that guides when a node transmits. When a node's data does not agree with its neighbors, that node communicates quickly to resolve the inconsistency (e.g., in milliseconds). When nodes agree, they slow their communication rate exponentially, such that nodes send packets very infrequently (e.g., a few packets per hour). Instead of flooding a network with packets, the algorithm controls the send rate so each node hears a small trickle of packets, just enough to stay consistent. Furthermore, by relying only on local communication (e.g., broadcast or local multicast), Trickle handles network re-population, is robust to network transience, loss, and disconnection, is simple to implement, and requires very little state. Current implementations use 4-11 bytes of RAM and are 50-200 lines of C code. While Trickle was originally designed for reprogramming protocols (where the data is the code of the program being updated), experience has shown it to be a powerful mechanism that can be applied to wide range of protocol design problems, including control traffic timing, multicast propagation, and route discovery. This flexibility stems from being able to define, on a case-by-case basis, what constitutes "agreement" or an "inconsistency;" This document describes the Trickle algorithm and provides guidelines for its use. It also states requirements for protocol specifications that use Trickle. This document does not provide results on Trickle's performance or behavior, nor does it explain the algorithm's design in detail. Working Group Summary No discontent. Document Quality The Trickle algorithm is a true component of the RPL routing protocol, specified by the ROLL WG, which has passed WG Last Call. Since RPL has been implemented by more than a dozens of implementation and several interoperability events took place, the trickle algorithm has also been successfully implemented (the reason for documenting trickle in a separate document was that it could be used in other circumstances than RPL) Personnel JP Vasseur (jvasseur@cisco.com) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. From jpv@cisco.com Tue Jan 11 23:50:33 2011 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 1F8663A69D9 for ; Tue, 11 Jan 2011 23:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.357 X-Spam-Level: X-Spam-Status: No, score=-111.357 tagged_above=-999 required=5 tests=[AWL=1.241, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 Ct-f3kqLZX1o for ; Tue, 11 Jan 2011 23:50:31 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 133893A69AE for ; Tue, 11 Jan 2011 23:50:29 -0800 (PST) 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: ApkEAKrsLE2Q/khMgWdsb2JhbACkPRUBARYiJKMvmHuDB4JFBIUjhHV0gyY Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 12 Jan 2011 07:52:48 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0C7qmTO014337 for ; Wed, 12 Jan 2011 07:52:48 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Jan 2011 08:52:47 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Jan 2011 08:52:47 +0100 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-101-831470702 Date: Wed, 12 Jan 2011 08:52:46 +0100 References: <20110111185038.DC9FE3A6A7E@core3.amsl.com> To: ROLL WG Message-Id: <9BEC20D0-CC52-4DE0-9B77-C746D3298DDC@cisco.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 12 Jan 2011 07:52:47.0069 (UTC) FILETIME=[B3D738D0:01CBB22D] Subject: [Roll] Fwd: IAB and INT Area Workshop on "Interconnecting Smart Objects with the Internet" 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 Jan 2011 07:50:33 -0000 --Apple-Mail-101-831470702 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear all, You may want to read this message and potentially submit a position = paper. Kind Regards. JP. Begin forwarded message: > From: IETF Secretariat > Date: January 11, 2011 7:50:38 PM GMT+01:00 > To: IETF Announcement list > Subject: IAB and INT Area Workshop on "Interconnecting Smart Objects = with the Internet"=20 >=20 > The Internet Architecture Board and the IETF Internet Area will hold a > workshop on the Friday, 25th March 2011 in Prague on the topic: >=20 > "Interconnecting Smart Objects with the Internet" >=20 > Attached to this workshop is a tutorial day on the same topic on > Saturday, 26th March 2011. Please find more information about it at: > http://www.iab.org/about/workshops/smartobjects/tutorial.html >=20 > - Background >=20 > Today's Internet is experienced by users as a set of applications, = such > as email, instant messaging, and social networks. While these = applications > do not require users to be present at the time of service execution in > many cases they are. There are also substantial differences in = performance > between the various end devices, but in general end devices = participating > in the Internet are considered to have high performance. >=20 > As we move forward with the interconnection of all kinds of devices = via > the Internet, these characteristics will change. The term "Internet of > Things" denotes a trend where a large number of devices benefit from > communication services that use Internet protocols. Many of these = devices > are not directly operated by humans, but exist as components in = buildings, > vehicles, and the environment. There will be a lot of variation in the > computing power, available memory, and communications bandwidth = between > different types of devices. >=20 > Many of these devices provide new services or provide more value for > previously unconnected devices. Some devices have been connected in > various legacy ways in the past but are now migrating to the use of = the > Internet Protocol, sharing the same communications medium between all > applications and enabling rich communications services. >=20 > Much of this development can simply run on existing Internet = protocols. > For instance, home entertainment and monitoring systems often offer a = web > interface to the end user. In many cases the new, constrained = environments > can benefit from additional protocols that help optimize the > communications and lower the computational requirements. Examples of > standardization efforts targeted for these environments include the > "Constrained RESTful Environments (CoRE)", IPv6 over Low power WPAN > (6LoWPAN)", and Routing Over Low power and Lossy networks (ROLL)" = working > groups at the IETF. >=20 > This workshop aims to explore the experience and approaches taken by > researchers and developers of Internet technology, when considering = the > characteristics of constrained devices. Engineers know that many = design > considerations need to be taken into account when developing protocols = and > architecture. Balancing between the conflicting goals of computing > performance, code size, economical incentives, and security is often > difficult, as illustrated by Clark, et al. in "Tussle in Cyberspace: > Defining Tomorrow's Internet", see > http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf >=20 > This workshop aims to discuss the experience and approaches taken when > designing protocols and architectures for interconnecting smart = objects to > the Internet. To frame the discussion we suggest, as examples, to > investigate the area of integration in the following categories: > * Scalability > * Power efficiency > * Interworking between different technologies and network domains > * Usability and manageability > * Security and Privacy >=20 > The goal of the IETF is "to make the Internet work better" and the > workshop organizers are interested in receiving contributions that = support > this goal. Results may lead to guidelines and recommendations, = proposals > for new standards development, start of new research activities, and = the > documentation of best current practices regarding implementation and > configuration. >=20 > - Workshop Style >=20 > The workshop=82s main focus will be on the discussions of technical = topics. > (This is not a mini-conference where every author just briefly talks = about > their papers.) >=20 > In order to keep the group at a manageable size, participants are > required to submit a position paper as an expression of interest. > Submitters of accepted position papers will be invited to attend the > workshop. Active participation will be expected. >=20 > The workshop will be structured as a series of working sessions > punctuated by invited speakers who will present relevant background > information or controversial ideas that help participants reach a = deeper > understanding of the subject. The organizing committee may ask = submitters > of particularly salient papers to present their ideas and experiences = at > the workshop. For each slot, there will be one or two invited > controversial speakers, and group work on the problem that=82s = identified, > hopefully reaching either a deeper understanding of the problem or = some > means of approaching it. >=20 > - Important Dates >=20 > Position papers must be submitted at latest February, 11th, 2011. = Note: > An early submission allows us to provide you feedback! >=20 > Submitted position papers will be reviewed immediately by the program > organizers and an invitation to the workshop will be sent to one of = the > paper authors. At the latest, invitations will be distributed by = February, > 25th. >=20 > This one-day workshop will take place on Friday, 25th March, 2011, = right > before the 80th IETF meeting in Prague, which starts on Sunday, 27th > March. Independent of this workshop but relevant for the participants, = are > tutorial events on Saturday, 26th March 2011. These tutorials will = focus > on ongoing IETF efforts related to the IETF CoRE, ROLL, and 6LoWPAN > working groups. More details can be found at: >=20 > - Position Paper Requirements >=20 > Interested parties must submit a brief contribution describing their = work > or approach, as it relates to the workshop theme. We welcome visionary > ideas for how to tackle the integration of constrained devices, as = well as > write-ups of deployment experience, and lessons-learned from = successful or > failed attempts at integrating these constrained devices with the > Internet. Contributions are not required to be original in content. >=20 > We solicit brief write-ups with 1 to 3 pages, formatted in HTML, PDF, = or > plain text (for example as a submitted Internet Draft). We encourage = paper > authors to limit themselves on the most important challenge. A focused > message will be key! Accepted position papers will be published (in > addition to meeting minutes, slides, and a workshop report). >=20 > Please send your position paper to iot-workshop-prep@lists.i1b.org. >=20 > - Venue >=20 > The planned date and location for the workshop is Friday, March 25th, = in > Prague. Details about the meeting venue will be provided to the = invited > workshop participants. During the breaks coffee and tea will be = served. >=20 > There are no plans for remote participation. Minutes of discussions = will > be available, and offers to organize audio recording would be gladly > appreciated. >=20 > - Workshop Organizers >=20 > We look forward to your input. The workshop organizers are Jari Arkko > (Internet Area Director), Hannes Tschofenig (IAB), Bernard Aboba = (IAB), > Carsten Bormann (CoRE and 6LoWPAN WG Chair), David Culler (ROLL WG = Chair), > Lars Eggert (Transport Area Director, and upcoming IRTF Chair), JP = Vasseur > (ROLL WG Chair), Stewart Bryant (Routing Area Director), Adrian Farrel > (Routing Area Director), Ralph Droms (Internet Area Director), = Geoffrey > Mulligan (6LoWPAN WG Chair), Alexey Melnikov (Applications Area = Director), > Peter Saint-Andre (Applications Area Director), Marcelo Bagnulo (IAB), > Zach Shelby (Smart Power Directorate), Isidro Ballesteros Laso = (European > Commission), Fred Baker (Member of the Smart Power Directorate and = liaison > to the US Smart Grid Interoperability Panel - SGIP). >=20 > Up-to-date information about the workshop is available at: > http://www.iab.org/about/workshops/smartobjects/ >=20 > Feel free to contact us at iot-workshop-prep@lists.i1b.org. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-101-831470702 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = all,

You may want to read this message and = potentially submit a position paper.

Kind = Regards.

JP.

Begin forwarded = message:

From: IETF Secretariat <ietf-secretariat@ietf.org>= ;
Date: January 11, 2011 7:50:38 PM = GMT+01:00
To: IETF Announcement list <ietf-announce@ietf.org>
<= /span>
Subject: IAB and INT Area Workshop on "Interconnecting = Smart Objects with the Internet"

The = Internet Architecture Board and the IETF Internet Area will hold = a
workshop on the Friday, 25th March 2011 in Prague on the = topic:

"Interconnecting Smart Objects with the = Internet"

Attached to this workshop is a tutorial day on the same = topic on
Saturday, 26th March 2011. Please find more information = about it at:
htt= p://www.iab.org/about/workshops/smartobjects/tutorial.html

- = Background

Today's Internet is experienced by users as a set of = applications, such
as email, instant messaging, and social networks. = While these applications
do not require users to be present at the = time of service execution in
many cases they are. There are also = substantial differences in performance
between the various end = devices, but in general end devices participating
in the Internet are = considered to have high performance.

As we move forward with the = interconnection of all kinds of devices via
the Internet, these = characteristics will change. The term "Internet of
Things" denotes a = trend where a large number of devices benefit from
communication = services that use Internet protocols. Many of these devices
are not = directly operated by humans, but exist as components in = buildings,
vehicles, and the environment. There will be a lot of = variation in the
computing power, available memory, and = communications bandwidth between
different types of = devices.

Many of these devices provide new services or provide = more value for
previously unconnected devices. Some devices have been = connected in
various legacy ways in the past but are now migrating to = the use of the
Internet Protocol, sharing the same communications = medium between all
applications and enabling rich communications = services.

Much of this development can simply run on existing = Internet protocols.
For instance, home entertainment and monitoring = systems often offer a web
interface to the end user. In many cases = the new, constrained environments
can benefit from additional = protocols that help optimize the
communications and lower the = computational requirements. Examples of
standardization efforts = targeted for these environments include the
"Constrained RESTful = Environments (CoRE)", IPv6 over Low power WPAN
(6LoWPAN)", and = Routing Over Low power and Lossy networks (ROLL)" working
groups at = the IETF.

This workshop aims to explore the experience and = approaches taken by
researchers and developers of Internet = technology, when considering the
characteristics of constrained = devices. Engineers know that many design
considerations need to be = taken into account when developing protocols and
architecture. = Balancing between the conflicting goals of computing
performance, = code size, economical incentives, and security is often
difficult, as = illustrated by Clark, et al. in "Tussle in Cyberspace:
Defining = Tomorrow's Internet", = see
http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf=

This workshop aims to discuss the experience and approaches = taken when
designing protocols and architectures for interconnecting = smart objects to
the Internet. To frame the discussion we suggest, as = examples, to
investigate the area of integration in the following = categories:
* Scalability
* Power efficiency
* Interworking = between different technologies and network domains
* Usability and = manageability
* Security and Privacy

The goal of the IETF is = "to make the Internet work better" and the
workshop organizers are = interested in receiving contributions that support
this goal. Results = may lead to guidelines and recommendations, proposals
for new = standards development, start of new research activities, and = the
documentation of best current practices regarding implementation = and
configuration.

- Workshop Style

The workshop=82s = main focus will be on the discussions of technical topics.
(This is = not a mini-conference where every author just briefly talks = about
their papers.)

In order to keep the group at a = manageable size, participants are
required to submit a position paper = as an expression of interest.
Submitters of accepted position papers = will be invited to attend the
workshop. Active participation will be = expected.

The workshop will be structured as a series of working = sessions
punctuated by invited speakers who will present relevant = background
information or controversial ideas that help participants = reach a deeper
understanding of the subject. The organizing committee = may ask submitters
of particularly salient papers to present their = ideas and experiences at
the workshop. For each slot, there will be = one or two invited
controversial speakers, and group work on the = problem that=82s identified,
hopefully reaching either a deeper = understanding of the problem or some
means of approaching = it.

- Important Dates

Position papers must be submitted at = latest February, 11th, 2011. Note:
An early submission allows us to = provide you feedback!

Submitted position papers will be reviewed = immediately by the program
organizers and an invitation to the = workshop will be sent to one of the
paper authors. At the latest, = invitations will be distributed by February,
25th.

This = one-day workshop will take place on Friday, 25th March, 2011, = right
before the 80th IETF meeting in Prague, which starts on Sunday, = 27th
March. Independent of this workshop but relevant for the = participants, are
tutorial events on Saturday, 26th March 2011. These = tutorials will focus
on ongoing IETF efforts related to the IETF = CoRE, ROLL, and 6LoWPAN
working groups. More details can be found = at:

- Position Paper Requirements

Interested parties must = submit a brief contribution describing their work
or approach, as it = relates to the workshop theme. We welcome visionary
ideas for how to = tackle the integration of constrained devices, as well as
write-ups = of deployment experience, and lessons-learned from successful = or
failed attempts at integrating these constrained devices with = the
Internet. Contributions are not required to be original in = content.

We solicit brief write-ups with 1 to 3 pages, formatted = in HTML, PDF, or
plain text (for example as a submitted Internet = Draft). We encourage paper
authors to limit themselves on the most = important challenge. A focused
message will be key! Accepted position = papers will be published (in
addition to meeting minutes, slides, and = a workshop report).

Please send your position paper to = iot-workshop-prep@lists.i1b.org.

- Venue

The planned date = and location for the workshop is Friday, March 25th, in
Prague. = Details about the meeting venue will be provided to the = invited
workshop participants. During the breaks coffee and tea will = be served.

There are no plans for remote participation. Minutes = of discussions will
be available, and offers to organize audio = recording would be gladly
appreciated.

- Workshop = Organizers

We look forward to your input. The workshop organizers = are Jari Arkko
(Internet Area Director), Hannes Tschofenig (IAB), = Bernard Aboba (IAB),
Carsten Bormann (CoRE and 6LoWPAN WG Chair), = David Culler (ROLL WG Chair),
Lars Eggert (Transport Area Director, = and upcoming IRTF Chair), JP Vasseur
(ROLL WG Chair), Stewart Bryant = (Routing Area Director), Adrian Farrel
(Routing Area Director), Ralph = Droms (Internet Area Director), Geoffrey
Mulligan (6LoWPAN WG Chair), = Alexey Melnikov (Applications Area Director),
Peter Saint-Andre = (Applications Area Director), Marcelo Bagnulo (IAB),
Zach Shelby = (Smart Power Directorate), Isidro Ballesteros Laso = (European
Commission), Fred Baker (Member of the Smart Power = Directorate and liaison
to the US Smart Grid Interoperability Panel - = SGIP).

Up-to-date information about the workshop is available = at:
http://www.iab.org/about/workshops/smartobjects/

Feel free = to contact us at = iot-workshop-prep@lists.i1b.org.
______________________________________= _________
IETF-Announce mailing = list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ie= tf-announce

= --Apple-Mail-101-831470702-- From ulrich@herberg.name Wed Jan 12 07:29:53 2011 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 52F7C28C107 for ; Wed, 12 Jan 2011 07:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, 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 dUhwD7NX39Si for ; Wed, 12 Jan 2011 07:29:52 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 70C9828C128 for ; Wed, 12 Jan 2011 07:29:52 -0800 (PST) Received: by qwi2 with SMTP id 2so729957qwi.31 for ; Wed, 12 Jan 2011 07:32:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.245.14 with SMTP id ls14mr986477qcb.19.1294846331892; Wed, 12 Jan 2011 07:32:11 -0800 (PST) Received: by 10.220.182.193 with HTTP; Wed, 12 Jan 2011 07:32:11 -0800 (PST) Date: Wed, 12 Jan 2011 16:32:11 +0100 Message-ID: From: Ulrich Herberg To: roll WG Content-Type: multipart/alternative; boundary=0016362849f8a6bec80499a7e7af Subject: [Roll] Question about 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: Wed, 12 Jan 2011 15:29:53 -0000 --0016362849f8a6bec80499a7e7af Content-Type: text/plain; charset=ISO-8859-1 Hi, I have a question about the DAO-ACK in non-storing mode. When the root receives a (unicast) DAO, how can it sent back the (unicast) DAO-ACK to the node? It is possible that the root has not yet received all other DAOs from nodes along the path to the node that sent the DAO (e.g. because some of the DAOs have been lost). What happens then? Another thing: In section 6.5.3., there are no DAO-ACK options listed. But shouldn't the padding options be allowed (as mentioned in sections 6.7.2 and 6.7.3) Thanks Ulrich --0016362849f8a6bec80499a7e7af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I have a question about the DAO-ACK in non-storing mode. When th= e root receives a (unicast) DAO, how can it sent back the (unicast) DAO-ACK= to the node? It is possible that the root has not yet received all other D= AOs from nodes along the path to the node that sent the DAO (e.g. because s= ome of the DAOs have been lost). What happens then?

Another thing: In section 6.5.3., there are no DAO-ACK options listed. = But shouldn't the padding options be allowed (as mentioned in sections = 6.7.2 and 6.7.3)

Thanks
Ulrich
--0016362849f8a6bec80499a7e7af-- From Matteo.Paris@ember.com Wed Jan 12 11:34:34 2011 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 47E333A6A3D for ; Wed, 12 Jan 2011 11:34:34 -0800 (PST) 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=[AWL=0.000, 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 1FohSli3ecxu for ; Wed, 12 Jan 2011 11:34:33 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4888B3A6A4C for ; Wed, 12 Jan 2011 11:34:33 -0800 (PST) Received: from [192.168.1.101] ([192.168.90.100]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Jan 2011 14:36:52 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 12 Jan 2011 14:36:50 -0500 To: Ulrich Herberg , roll WG From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 12 Jan 2011 19:36:52.0349 (UTC) FILETIME=[0FFD62D0:01CBB290] Subject: Re: [Roll] Question about 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: Wed, 12 Jan 2011 19:34:34 -0000 Hi Ulrich. Indeed this happens frequently when starting a new DODAG instance in non-storing mode. Depending on DAO delay and jitter settings, it takes a few seconds or more for the first wave of of DAOs to come in from the network. At the time a given DAO arrives, the root may not yet have a complete path back out to be able to route a DAO-ACK in return. However this will generally be remedied by the time the node in question retries the DAO since the other nodes in the network will have had time to send in their first DAO. If not, there are always more retries. The root could store the knowledge that it owes a DAO-ACK, and send it out as soon as it has gathered sufficient source-routing information, but it's less code to just forget about it and wait for the next DAO retry. Note that you can also play with the DAO delay timing, which is left open by the RPL spec. The typical thing is to set the DAODelay to be proportional to rank, so that DAOs from routers closest to the root arrive first, which avoids using bandwidth for extra retries. (This is exactly the reverse of the DAODelay optimization suggestion made for storing mode in section 9.6, since in that case it is desirable for the leaf nodes to send their DAOs first so the information can be aggregated more efficiently.) During DAG formation, the further from the root a node is, the longer it takes for the parent set to settle down. So waiting a bit longer also helps avoid an initial proliferation of DAOs caused by fluctuating parent sets. The tradeoff is an increase in the amount of time for the root to obtain a complete set of downward routes, which may be a concern. Matteo At 4:32 PM +0100 1/12/11, Ulrich Herberg wrote: >Hi, > >I have a question about the DAO-ACK in non-storing mode. When the >root receives a (unicast) DAO, how can it sent back the (unicast) >DAO-ACK to the node? It is possible that the root has not yet >received all other DAOs from nodes along the path to the node that >sent the DAO (e.g. because some of the DAOs have been lost). What >happens then? > >Another thing: In section 6.5.3., there are no DAO-ACK options >listed. But shouldn't the padding options be allowed (as mentioned >in sections 6.7.2 and 6.7.3) > >Thanks >Ulrich > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From prvs=987edf0a2=Tzeta.Tsao@cooperindustries.com Thu Jan 13 14:08:22 2011 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 3297B3A6BEA for ; Thu, 13 Jan 2011 14:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 2lMc+NtDk9hG for ; Thu, 13 Jan 2011 14:08:15 -0800 (PST) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by core3.amsl.com (Postfix) with ESMTP id 8567B3A67C2 for ; Thu, 13 Jan 2011 14:08:15 -0800 (PST) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,319,1291611600"; d="scan'208";a="83854962" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 13 Jan 2011 17:10:38 -0500 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 17:10:38 -0500 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: Thu, 13 Jan 2011 17:10:04 -0500 Message-ID: <9BB070DB2D281946859EA89837931EEE459BD0@EVS4.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-roll-security-framework-04 Thread-Index: AcuzbhKnI1ebHF4aRmuzgd7wpBHk9gAABKUA From: "Tsao, Tzeta" To: X-OriginalArrivalTime: 13 Jan 2011 22:10:38.0542 (UTC) FILETIME=[B5A476E0:01CBB36E] Cc: david.black@emc.com, adrian.farrel@huawei.com, culler@eecs.berkeley.edu Subject: [Roll] FW: New Version Notification for draft-ietf-roll-security-framework-04 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 Jan 2011 22:08:22 -0000 V0csDQoNCldlIGhhdmUgcG9zdGVkIGRyYWZ0LWlldGYtcm9sbC1zZWN1cml0eS1mcmFtZXdvcmst MDQsIHdoaWNoIHNob3VsZCBiZSBhdmFpbGFibGUgZnJvbSB0aGUgcmVwb3NpdG9yeSBzaG9ydGx5 LiBUaGUgbWFpbiBjaGFuZ2VzIGFyZSB0byBhZGRyZXNzIEdlbi1BUlQncyBjb21tZW50cy4gTmV3 IHRleHRzIGFyZSBpbnRyb2R1Y2VkIHRvIGJldHRlciBleHBsYWluIHRoZSBkZXJpdmF0aW9uIG9m IHRocmVhdHMgYW5kIGF0dGFja3MsIGFzIHdlbGwgYXMgdGhlIHVzZSBvZiBub3JtYXRpdmUgbGFu Z3VhZ2VzLiBNaXNzZWQgcG9pbnRzIGFyZSBtZW5kZWQgYW5kIHN0cm9uZ2VyIHJhdGlvbmFsZSBm b3IgU2VjdGlvbiA3IGlzIHByb3ZpZGVkLg0KDQpUaGFua3MsDQpUemV0YQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIFttYWlsdG86 aWRzdWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDEzLCAyMDEx IDU6MDQgUE0NClRvOiBUc2FvLCBUemV0YQ0KQ2M6IEFsZXhhbmRlciwgUm9nZXI7IG1pc2NoYS5k b2hsZXJAY3R0Yy5lczsgdmFuZXNhLmRhemFAdXBmLmVkdTsgYW5nZWwubG96YW5vQHVwZi5lZHUN ClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1yb2xsLXNl Y3VyaXR5LWZyYW1ld29yay0wNCANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0 Zi1yb2xsLXNlY3VyaXR5LWZyYW1ld29yay0wNC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBUemV0YSBUc2FvIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4N Cg0KRmlsZW5hbWU6CSBkcmFmdC1pZXRmLXJvbGwtc2VjdXJpdHktZnJhbWV3b3JrDQpSZXZpc2lv bjoJIDA0DQpUaXRsZToJCSBBIFNlY3VyaXR5IEZyYW1ld29yayBmb3IgUm91dGluZyBvdmVyIExv dyBQb3dlciBhbmQgTG9zc3kgTmV0d29ya3MNCkNyZWF0aW9uX2RhdGU6CSAyMDExLTAxLTEzDQpX RyBJRDoJCSByb2xsDQpOdW1iZXJfb2ZfcGFnZXM6IDQ2DQoNCkFic3RyYWN0Og0KVGhpcyBkb2N1 bWVudCBwcmVzZW50cyBhIHNlY3VyaXR5IGZyYW1ld29yayBmb3Igcm91dGluZyBvdmVyIGxvdw0K cG93ZXIgYW5kIGxvc3N5IG5ldHdvcmtzIChMTE4pLiAgVGhlIGRldmVsb3BtZW50IGJ1aWxkcyB1 cG9uIHByZXZpb3VzDQp3b3JrIG9uIHJvdXRpbmcgc2VjdXJpdHkgYW5kIGFkYXB0cyB0aGUgYXNz ZXNzbWVudHMgdG8gdGhlIGlzc3VlcyBhbmQNCmNvbnN0cmFpbnRzIHNwZWNpZmljIHRvIGxvdyBw b3dlciBhbmQgbG9zc3kgbmV0d29ya3MuICBBIHN5c3RlbWF0aWMNCmFwcHJvYWNoIGlzIHVzZWQg aW4gZGVmaW5pbmcgYW5kIGV2YWx1YXRpbmcgdGhlIHNlY3VyaXR5IHRocmVhdHMgYW5kDQppZGVu dGlmeWluZyBhcHBsaWNhYmxlIGNvdW50ZXJtZWFzdXJlcy4gIFRoZXNlIGFzc2Vzc21lbnRzIHBy b3ZpZGUNCnRoZSBiYXNpcyBvZiB0aGUgc2VjdXJpdHkgcmVjb21tZW5kYXRpb25zIGZvciBpbmNv cnBvcmF0aW9uIGludG8gbG93DQpwb3dlciwgbG9zc3kgbmV0d29yayByb3V0aW5nIHByb3RvY29s cy4gIEFzIGFuIGlsbHVzdHJhdGlvbiwgdGhpcw0KZnJhbWV3b3JrIGlzIGFwcGxpZWQgdG8gSVB2 NiBSb3V0aW5nIFByb3RvY29sIGZvciBMb3cgUG93ZXIgYW5kIExvc3N5DQpOZXR3b3JrcyAoUlBM KS4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdC4N Cg0KDQo= From Internet-Drafts@ietf.org Thu Jan 13 14:15:02 2011 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 B07F43A6BFA; Thu, 13 Jan 2011 14:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, 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 M3JPYx1zjGlt; Thu, 13 Jan 2011 14:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9293A6BEC; Thu, 13 Jan 2011 14:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110113221501.24066.45527.idtracker@localhost> Date: Thu, 13 Jan 2011 14:15:01 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-security-framework-04.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: Thu, 13 Jan 2011 22:15:02 -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 : A Security Framework for Routing over Low Power and Lossy Networks Author(s) : T. Tsao, et al. Filename : draft-ietf-roll-security-framework-04.txt Pages : 46 Date : 2011-01-13 This document presents a security framework for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-security-framework-04.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-security-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-13140339.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Thu Jan 13 22:30:02 2011 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 789923A68D1; Thu, 13 Jan 2011 22:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, 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 7CUgkM6QV0M2; Thu, 13 Jan 2011 22:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8986D3A6A91; Thu, 13 Jan 2011 22:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110114063001.12439.70202.idtracker@localhost> Date: Thu, 13 Jan 2011 22:30:01 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-15.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, 14 Jan 2011 06:30:02 -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 : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, et al. Filename : draft-ietf-roll-routing-metrics-15.txt Pages : 30 Date : 2011-01-13 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-15.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-routing-metrics-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-13222759.I-D@ietf.org> --NextPart-- From jpv@cisco.com Thu Jan 13 22:34:53 2011 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 46DC528C11E for ; Thu, 13 Jan 2011 22:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.404 X-Spam-Level: X-Spam-Status: No, score=-110.404 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8, 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 WGgRAytYwyAi for ; Thu, 13 Jan 2011 22:34:51 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 551A83A6AAE for ; Thu, 13 Jan 2011 22:34:50 -0800 (PST) Authentication-Results: ams-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: AqAHAFN+L02Q/khMgWdsb2JhbACcYYcVXhUBARYiJKUkmFWFTwSLFoMo Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 14 Jan 2011 06:36:59 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0E6axbN030596 for ; Fri, 14 Jan 2011 06:36:59 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 07:36:58 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 07:36:58 +0100 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-133-999722103 Date: Fri, 14 Jan 2011 07:36:58 +0100 References: <20110114063001.12439.70202.idtracker@localhost> To: ROLL WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 14 Jan 2011 06:36:58.0231 (UTC) FILETIME=[71592070:01CBB3B5] Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-15.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, 14 Jan 2011 06:34:53 -0000 --Apple-Mail-133-999722103 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, This revision incorporated the comments from Gen-art review and security = directorate. Thanks ! JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: January 14, 2011 7:30:01 AM GMT+01:00 > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: I-D Action:draft-ietf-roll-routing-metrics-15.txt > Reply-To: internet-drafts@ietf.org >=20 > 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. >=20 >=20 > Title : Routing Metrics used for Path Calculation in = Low Power and Lossy Networks > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-roll-routing-metrics-15.txt > Pages : 30 > Date : 2011-01-13 >=20 > Low power and Lossy Networks (LLNs) have unique characteristics > compared with traditional wired and ad-hoc networks that require the > specification of new routing metrics and constraints. By contrast > with typical Interior Gateway Protocol (IGP) routing metrics using > hop counts or link metrics, this document specifies a set of link and > node routing metrics and constraints suitable to LLNs to be used by > the Routing for Low Power and lossy networks (RPL) routing protocol. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-15.txt= >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-133-999722103 Content-Type: multipart/mixed; boundary=Apple-Mail-134-999722104 --Apple-Mail-134-999722104 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: January 14, 2011 7:30:01 AM = GMT+01:00
Subject: I-D = Action:draft-ietf-roll-routing-metrics-15.txt
Reply-To: internet-drafts@ietf.org
<= /span>

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 =           : Routing = Metrics used for Path Calculation in Low Power and Lossy = Networks
= Author(s)       : J. Vasseur, et = al.
= Filename        : = draft-ietf-roll-routing-metrics-15.txt
Pages =           : = 30
= Date =            : = 2011-01-13

Low power and Lossy Networks (LLNs) have unique = characteristics
compared with traditional wired and ad-hoc networks = that require the
specification of new routing metrics and = constraints.  By contrast
with typical Interior Gateway Protocol = (IGP) routing metrics using
hop counts or link metrics, this document = specifies a set of link and
node routing metrics and constraints = suitable to LLNs to be used by
the Routing for Low Power and lossy = networks (RPL) routing protocol.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metr= ics-15.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.
= --Apple-Mail-134-999722104 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2011-01-13222759.I-D@ietf.org>

--Apple-Mail-134-999722104 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-134-999722104-- --Apple-Mail-133-999722103-- From ulrich@herberg.name Fri Jan 14 01:54:04 2011 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 EBEEF3A6AC9 for ; Fri, 14 Jan 2011 01:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 0lIFN-lRVTgr for ; Fri, 14 Jan 2011 01:54:04 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id D54B73A6A0D for ; Fri, 14 Jan 2011 01:54:03 -0800 (PST) Received: by qyj19 with SMTP id 19so2940395qyj.10 for ; Fri, 14 Jan 2011 01:56:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.245.14 with SMTP id ls14mr537266qcb.19.1294998986797; Fri, 14 Jan 2011 01:56:26 -0800 (PST) Received: by 10.220.182.193 with HTTP; Fri, 14 Jan 2011 01:56:26 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Jan 2011 10:56:26 +0100 Message-ID: From: Ulrich Herberg To: Matteo Paris Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll WG Subject: Re: [Roll] Question about 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: Fri, 14 Jan 2011 09:54:05 -0000 Hi Matteo, thanks for your reply! That clarified a few things. I suggest that this should be specified in the RPL spec. On Wed, Jan 12, 2011 at 8:36 PM, Matteo Paris wrote: > > Hi Ulrich. =A0Indeed this happens frequently when starting a new DODAG in= stance in non-storing mode. =A0Depending on DAO delay and jitter settings, = it takes a few seconds or more for the first wave of of DAOs to come in fro= m the network. =A0At the time a given DAO arrives, the root may not yet hav= e a complete path back out to be able to route a DAO-ACK in return. =A0Howe= ver this will generally be remedied by the time the node in question retrie= s the DAO since the other nodes in the network will have had time to send i= n their first DAO. If not, there are always more retries. Yes, true. However, the RPL spec. says that the number of retries may be bounded. So it could happen that a node has stopped sending DAOs, before the root has received any, or before any DAO-ACK has been sucessfully received by the node (DAO-ACKs could also be lost). Also, it is unclear to me, how the DAOs are timed, when multiple are sent (exponential backoff timer? periodic? which interval? That could also have some relations with the DAODelay, see below). > The root could store the knowledge that it owes a DAO-ACK, and send it ou= t as soon as it has gathered sufficient source-routing information, but it'= s less code to just forget about it and wait for the next DAO retry. Yes, that are two valid possibilities that should be specified in RPL. > Note that you can also play with the DAO delay timing, which is left open= by the RPL spec. =A0The typical thing is to set the DAODelay to be proport= ional to rank, so that DAOs from routers closest to the root arrive first, = which avoids using bandwidth for extra retries. True, that may help, but only if no DAOs from nodes with a lower rank are lost. If some are lost, DAOs from nodes with a higher rank (and higher DAODelay) could still arrive before the DAOs from nodes with a lower rank. >=A0(This is exactly the reverse of the DAODelay optimization suggestion ma= de for storing mode in section 9.6, since in that case it is desirable for = the leaf nodes to send their DAOs first so the information can be aggregate= d more efficiently.) =A0During DAG formation, the further from the root a n= ode is, the longer it takes for the parent set to settle down. =A0So waitin= g a bit longer also helps avoid an initial proliferation of DAOs caused by = fluctuating parent sets. =A0The tradeoff is an increase in the amount of ti= me for the root to obtain a complete set of downward routes, which may be a= concern. Yes, I agree. Another question: what happens if no DAO-ACKs are used? It could happen that a node sends several DAOs, but none of them arrives at the root. When an upper bound for the number of DAOs to send is used, the node would eventually stop sending DAOs, believing that the root has received at least one. But neither the root would know about the node (i.e. would not have a route towards the node), nor would the node know that the root does not have a route. That seems like a bad situation. Thanks Ulrich > > Matteo > > At 4:32 PM +0100 1/12/11, Ulrich Herberg wrote: >> >> Hi, >> >> I have a question about the DAO-ACK in non-storing mode. When the root r= eceives a (unicast) DAO, how can it sent back the (unicast) DAO-ACK to the = node? It is possible that the root has not yet received all other DAOs from= nodes along the path to the node that sent the DAO (e.g. because some of t= he DAOs have been lost). What happens then? >> >> Another thing: In section 6.5.3., there are no DAO-ACK options listed. B= ut shouldn't the padding options be allowed (as mentioned in sections 6.7.2= and 6.7.3) >> >> Thanks >> Ulrich >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From ulrich@herberg.name Fri Jan 14 02:26:36 2011 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 447553A6ACE for ; Fri, 14 Jan 2011 02:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ZeRgYETrFZAh for ; Fri, 14 Jan 2011 02:26:35 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id BBB7D3A6AC9 for ; Fri, 14 Jan 2011 02:26:34 -0800 (PST) Received: by qyk34 with SMTP id 34so6234804qyk.10 for ; Fri, 14 Jan 2011 02:28:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.2.201 with SMTP id 9mr544623qak.109.1295000938158; Fri, 14 Jan 2011 02:28:58 -0800 (PST) Received: by 10.220.182.193 with HTTP; Fri, 14 Jan 2011 02:28:58 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Jan 2011 11:28:58 +0100 Message-ID: From: Ulrich Herberg To: Matteo Paris Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll WG Subject: Re: [Roll] Question about 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: Fri, 14 Jan 2011 10:26:36 -0000 P.S. another question concerning the time when DAOs are sent: (still in non-storing mode) The spec says that DAOs can be sent when "the Path Lifetime is to be updated (e.g. a refresh or a no-Path)" (section 9.2.1). At what time exactly does that mean? I assume that a node should keep a timer how long the target is "fresh", and send a DAO _before_ it expires at the root. How long before? (note that the DAO could be lost). Is jitter used? Otherwise, adjacent nodes could periodically send "refresh" DAOs for their target at the same time, leading to collisions. How many DAOs are sent at each refresh (in which intervals)? It would be much clearer for me as implementer if the spec was more precise in many of these questions. Also, it is difficult to discern the parts for non-storing mode and for storing mode; they are often mixed up in section 9, while the mechanisms are quite different (even though they use a similar message format). Thanks for the clarifications Ulrich On Fri, Jan 14, 2011 at 10:56 AM, Ulrich Herberg wrot= e: > Hi Matteo, > > thanks for your reply! That clarified a few things. I suggest that > this should be specified in the RPL spec. > > > On Wed, Jan 12, 2011 at 8:36 PM, Matteo Paris wrote: >> >> Hi Ulrich. =A0Indeed this happens frequently when starting a new DODAG i= nstance in non-storing mode. =A0Depending on DAO delay and jitter settings,= it takes a few seconds or more for the first wave of of DAOs to come in fr= om the network. =A0At the time a given DAO arrives, the root may not yet ha= ve a complete path back out to be able to route a DAO-ACK in return. =A0How= ever this will generally be remedied by the time the node in question retri= es the DAO since the other nodes in the network will have had time to send = in their first DAO. If not, there are always more retries. > > Yes, true. However, the RPL spec. says that the number of retries may > be bounded. So it could happen that a node has stopped sending DAOs, > before the root has received any, or before any DAO-ACK has been > sucessfully received by the node (DAO-ACKs could also be lost). Also, > it is unclear to me, how the DAOs are timed, when multiple are sent > (exponential backoff timer? periodic? which interval? That could also > have some relations with the DAODelay, see below). > > >> The root could store the knowledge that it owes a DAO-ACK, and send it o= ut as soon as it has gathered sufficient source-routing information, but it= 's less code to just forget about it and wait for the next DAO retry. > > Yes, that are two valid possibilities that should be specified in RPL. > > >> Note that you can also play with the DAO delay timing, which is left ope= n by the RPL spec. =A0The typical thing is to set the DAODelay to be propor= tional to rank, so that DAOs from routers closest to the root arrive first,= which avoids using bandwidth for extra retries. > > True, that may help, but only if no DAOs from nodes with a lower rank > are lost. If some are lost, DAOs from nodes with a higher rank (and > higher DAODelay) could still arrive before the DAOs from nodes with a > lower rank. > >>=A0(This is exactly the reverse of the DAODelay optimization suggestion m= ade for storing mode in section 9.6, since in that case it is desirable for= the leaf nodes to send their DAOs first so the information can be aggregat= ed more efficiently.) =A0During DAG formation, the further from the root a = node is, the longer it takes for the parent set to settle down. =A0So waiti= ng a bit longer also helps avoid an initial proliferation of DAOs caused by= fluctuating parent sets. =A0The tradeoff is an increase in the amount of t= ime for the root to obtain a complete set of downward routes, which may be = a concern. > > Yes, I agree. > > > Another question: what happens if no DAO-ACKs are used? It could > happen that a node sends several DAOs, but none of them arrives at the > root. When an upper bound for the number of DAOs to send is used, the > node would eventually stop sending DAOs, believing that the root has > received at least one. But neither the root would know about the node > (i.e. would not have a route towards the node), nor would the node > know that the root does not have a route. That seems like a bad > situation. > > > Thanks > Ulrich > > >> >> Matteo >> >> At 4:32 PM +0100 1/12/11, Ulrich Herberg wrote: >>> >>> Hi, >>> >>> I have a question about the DAO-ACK in non-storing mode. When the root = receives a (unicast) DAO, how can it sent back the (unicast) DAO-ACK to the= node? It is possible that the root has not yet received all other DAOs fro= m nodes along the path to the node that sent the DAO (e.g. because some of = the DAOs have been lost). What happens then? >>> >>> Another thing: In section 6.5.3., there are no DAO-ACK options listed. = But shouldn't the padding options be allowed (as mentioned in sections 6.7.= 2 and 6.7.3) >>> >>> Thanks >>> Ulrich >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> > From yoav@yitran.com Sun Jan 16 00:17:55 2011 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 4C0943A6D1A for ; Sun, 16 Jan 2011 00:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.821 X-Spam-Level: X-Spam-Status: No, score=-5.821 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 zsGWxOyHZqtI for ; Sun, 16 Jan 2011 00:17:53 -0800 (PST) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id 235DD3A6D19 for ; Sun, 16 Jan 2011 00:17:52 -0800 (PST) Received: from source ([209.85.161.49]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTTKqRwVH9zoSMQZM28ez492wCnSTXyWH@postini.com; Sun, 16 Jan 2011 00:20:24 PST Received: by fxm19 with SMTP id 19so4575508fxm.8 for ; Sun, 16 Jan 2011 00:20:22 -0800 (PST) Received: by 10.204.52.75 with SMTP id h11mr1513069bkg.67.1295166021055; Sun, 16 Jan 2011 00:20:21 -0800 (PST) From: Yoav Ben-Yehezkel References: <20110114063001.12439.70202.idtracker@localhost> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuztX+Dm/dKk/SRRoCv2u8v2zs6VQBmUbLg Date: Sun, 16 Jan 2011 10:18:06 +0200 Message-ID: <1772763cecca2e589a68ed6268a394cf@mail.gmail.com> To: JP Vasseur , ROLL WG Content-Type: multipart/alternative; boundary=001636c5ba379c34400499f256d0 Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-15.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, 16 Jan 2011 08:17:55 -0000 --001636c5ba379c34400499f256d0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi ROLL-ers, A few comments/questions to this version of the draft: 1. Flags field - in figure 2 for example, =93Flags=94 field in the fi= gure looks like it=92s 6 bits followed by A and O flag fields. In the text below= is defined as Flags (8 bits). Propose to add a clarification that the A and O flags are part of the Flags field. The same repeats in other figures as wel= l (for example Figure 1 and Figure 4). 2. Is the =93Prec=94 field really a flag? 3. Although he probably deserves it, but was it the intent of the authors to acknowledge Mukul Goyal twice? J 4. There seems to be two copies of the draft (2nd one starting at pag= e 30) Also, I propose to run a spell/grammar checker throughout the document. A few catches: 1. found one more instance of =93objet=94 instead of =93object=94 in = section 3. 2. in section 1: e.g =3D e.g. , characterisics =3D characteristics, unneccessary =3D unnecessary 3. in section 2.1: signalled =3D signaled 4. in section 4.3.2: cummulative =3D cumulative 5. in section 4.4.1: =93There MUST be a at least one LC sub-object = per LC object.=94 =96 remove =93a=94 after =93be=94 6. in section 7: intermitment =3D intermittent 7. In section 8: thourough =3D thorough 8. in section 4.3.1, the text =93(e.g. something like "select the pat= h with most links reporting a LQL value of 3 or less"=94 =96 propose to remov= e =93something like=94 =96 e.g. already means that it=92s something like. Best regards, Yoav *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of = *JP Vasseur *Sent:* Friday, January 14, 2011 8:37 AM *To:* ROLL WG *Subject:* [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-15.txt All, This revision incorporated the comments from Gen-art review and security directorate. Thanks ! JP. Begin forwarded message: *From: *Internet-Drafts@ietf.org *Date: *January 14, 2011 7:30:01 AM GMT+01:00 *To: *i-d-announce@ietf.org *Cc: *roll@ietf.org *Subject: I-D Action:draft-ietf-roll-routing-metrics-15.txt* *Reply-To: *internet-drafts@ietf.org 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 : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, et al. Filename : draft-ietf-roll-routing-metrics-15.txt Pages : 30 Date : 2011-01-13 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-15.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. --001636c5ba379c34400499f256d0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi ROLL-ers,

=A0

A few comments/questions to this version of the draft:

=A0

1.=A0=A0=A0=A0=A0=A0 2.=A0=A0=A0=A0=A0=A0 3.=A0=A0=A0=A0=A0=A0 J

4.=A0=A0=A0=A0=A0=A0 =A0

Also, I propose to run a spell/grammar checker throughout th= e document. A few catches:

1.=A0=A0=A0=A0=A0=A0 2.=A0=A0=A0=A0=A0=A0 3.=A0=A0=A0=A0=A0=A0 4.=A0=A0=A0=A0=A0=A0 5.=A0=A0=A0=A0=A0=A0 6.=A0=A0=A0=A0=A0=A0 7.=A0=A0=A0=A0=A0=A0 8.=A0=A0=A0=A0=A0=A0 =A0

Best regards,

Yoav

=A0

=A0

=A0

From: roll-bounces@ietf.org [mailto:= roll-bounces@ietf.org] On B= ehalf Of JP Vasseur
Sent: Friday, January 14, 2011 8:37 AM
To: ROLL WG
Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-15.t= xt

=A0

All,

=A0

This revision incorporated the comments from Gen-art= review and security directorate.

=A0

Thanks !

=A0

JP.

=A0

Begin forwarded message:



Date: January 14, 2011 7:30:01 AM GMT+01:00

Subject: I-D Action:draft-ietf-roll-routing-metrics-15.txt

=A0

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


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Tit= le =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: Routing Metrics used for Path Calculation in Low Power and Lossy Networks
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Aut= hor(s) =A0=A0=A0=A0=A0=A0: J. Vasseur, et al.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Fil= ename =A0=A0=A0=A0=A0=A0=A0: draft-ietf-roll-routing-metrics-15.txt
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Pag= es =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 30
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Dat= e =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 2011-01-13

Low power and Lossy Networks (LLNs) have unique characteristics
compared with traditional wired and ad-hoc networks that require the
specification of new routing metrics and constraints. =A0By contrast
with typical Interior Gateway Protocol (IGP) routing metrics using
hop counts or link metrics, this document specifies a set of link and
node routing metrics and constraints suitable to LLNs to be used by
the Routing for Low Power and lossy networks (RPL) routing protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-met= rics-15.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.

--001636c5ba379c34400499f256d0-- From Internet-Drafts@ietf.org Sun Jan 16 01:30:04 2011 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 759BE3A6D23; Sun, 16 Jan 2011 01:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, 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 BhKhJISlnkf8; Sun, 16 Jan 2011 01:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBD03A6CF8; Sun, 16 Jan 2011 01:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110116093001.1486.83738.idtracker@localhost> Date: Sun, 16 Jan 2011 01:30:01 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-16.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, 16 Jan 2011 09:30:05 -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 : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, et al. Filename : draft-ietf-roll-routing-metrics-16.txt Pages : 30 Date : 2011-01-16 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-16.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-routing-metrics-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-16011521.I-D@ietf.org> --NextPart-- From jpv@cisco.com Sun Jan 16 03:52:35 2011 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 E50C73A6E49 for ; Sun, 16 Jan 2011 03:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.416 X-Spam-Level: X-Spam-Status: No, score=-110.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 kXZ6hFy3qs3b for ; Sun, 16 Jan 2011 03:52:34 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9FE473A6E4A for ; Sun, 16 Jan 2011 03:52:34 -0800 (PST) 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: AvsEAOtqMk2Q/khLgWdsb2JhbACkaBYBFiIkpDSYDYVQBIsfgyo Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 16 Jan 2011 11:55:05 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0GBt5ob018205 for ; Sun, 16 Jan 2011 11:55:05 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jan 2011 12:55:04 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jan 2011 12:55:04 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: JP Vasseur In-Reply-To: <20110116093001.1486.83738.idtracker@localhost> Date: Sun, 16 Jan 2011 12:55:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7FF93339-B486-4C0F-BD90-4EAA77EE38EA@cisco.com> References: <20110116093001.1486.83738.idtracker@localhost> To: ROLL WG X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 16 Jan 2011 11:55:04.0544 (UTC) FILETIME=[3680DE00:01CBB574] Subject: Re: [Roll] I-D Action:draft-ietf-roll-routing-metrics-16.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, 16 Jan 2011 11:52:36 -0000 fixing an issue ... the content appeared twice in the document rev 15. JP. On Jan 16, 2011, at 10:30 AM, 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. >=20 >=20 > Title : Routing Metrics used for Path Calculation in = Low Power and Lossy Networks > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-roll-routing-metrics-16.txt > Pages : 30 > Date : 2011-01-16 >=20 > Low power and Lossy Networks (LLNs) have unique characteristics > compared with traditional wired and ad-hoc networks that require the > specification of new routing metrics and constraints. By contrast > with typical Interior Gateway Protocol (IGP) routing metrics using > hop counts or link metrics, this document specifies a set of link and > node routing metrics and constraints suitable to LLNs to be used by > the Routing for Low Power and lossy networks (RPL) routing protocol. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-16.txt= >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > 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 azdvir@gmail.com Mon Jan 17 04:59:10 2011 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 4A3563A6EF4 for ; Mon, 17 Jan 2011 04:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, 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 RhvTYsvV11p3 for ; Mon, 17 Jan 2011 04:59:09 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D55B53A6E49 for ; Mon, 17 Jan 2011 04:59:08 -0800 (PST) Received: by iwn40 with SMTP id 40so4999678iwn.31 for ; Mon, 17 Jan 2011 05:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=y7bDJtFV6LwVM+3+DdbSS5mJ0eLAH1LZTtynJ3JJ+IE=; b=PT/cRB0a6euX4kZ0jtXQ0ph28nIJxLG/Ix22vlVV92g5cn31LdsrhxsQilIQA+I/V7 EwbsV9O2O70oo01rYCo1ioV4uvR6jHNkLT5mxLDCxK/m0sdx8lj9im7dQ1ZpUjbVC9J4 Ci0LtA6daUhyo5eUo0sPyyXO/kauKgMdDXgCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=CLYxNEZvSThJhcM/2z4nLmUPKx3h0wer805arIT7z+upqNJUd1tPRXKDU3J9tr2cS6 7ls6pDxS3zbnt59GyXa9IHupIGGPp8j8DXi0tjFDcYX6EsbcbZBDfuqNUHoOa98X22Om OjUUg3Ay4Ih+Bi1PRlUXuvHql1arSOalZb4FA= Received: by 10.42.227.198 with SMTP id jb6mr4337717icb.520.1295269302810; Mon, 17 Jan 2011 05:01:42 -0800 (PST) Received: from amitPC (ip146.crysys.hit.bme.hu [152.66.249.146]) by mx.google.com with ESMTPS id u5sm3640200ics.18.2011.01.17.05.01.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Jan 2011 05:01:41 -0800 (PST) From: "amit dvir" To: Date: Mon, 17 Jan 2011 14:01:37 +0100 Message-ID: <028501cbb646$af727170$0e575450$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0286_01CBB64F.1136D970" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu2RqnjKD+I/WciSHWTnRV3JfvieQ== Content-Language: he Subject: [Roll] Security extensions to 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, 17 Jan 2011 12:59:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0286_01CBB64F.1136D970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Let me kindly inform you that in an EU funded research project on dependable sensor networks (www.wsan4cip.eu), we adopted RPL as the routing protocol in our protocol stack for demonstrators, and we designed some security extensions to RPL (not yet covered by the current RPL security features). Our intention is to submit these extensions as an Internet Draft to the ROLL Working Group. The New Internet-Draft is available from the on-line Internet-Drafts directories: https://datatracker.ietf.org/doc/draft-dvir-roll-security-extensions/ We would be happy to receive comments related to this work. We also would like to mention that we are developing an implementation of RPL both in a TinyOS and in a Linux environment. We plan to make our implementation including the security extensions we specified in the New Internet-Draft available to the community later this year. Best regards, Dr. Amit Dvir Crypto and System Security Lab (CrySyS) Budapest University of Technology www.crysys.hu ------=_NextPart_000_0286_01CBB64F.1136D970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Let me kindly = inform you that in an EU funded research project on dependable sensor = networks (www.wsan4cip.eu), we adopted RPL as the routing protocol in = our protocol stack for demonstrators, and we designed some security = extensions to RPL (not yet covered by the current RPL security = features).

 

Our intention = is to submit these extensions as an Internet Draft to the ROLL Working = Group. The New Internet-Draft is available from the on-line = Internet-Drafts directories:

 

https://datatracker.ietf.org/doc/draft-dvir-roll-security-extension= s/

 

 

We would be = happy to receive comments related to this work.

 

We also would = like to mention that we are developing an implementation of RPL both in = a TinyOS and in a Linux environment. We plan to make our implementation = including the security extensions we specified in the New = Internet-Draft available to the community later this = year.

 

 

Best = regards,

 

Dr. Amit = Dvir

Crypto and = System Security Lab (CrySyS)

Budapest = University of Technology

www.crysys.hu<= o:p>

 

------=_NextPart_000_0286_01CBB64F.1136D970-- From Adrian.Farrel@huawei.com Wed Jan 19 03:29:26 2011 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 D11823A6F2A for ; Wed, 19 Jan 2011 03:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.944 X-Spam-Level: X-Spam-Status: No, score=-102.944 tagged_above=-999 required=5 tests=[AWL=-1.546, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_42=0.6, 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 ozF0-0YG+YLE for ; Wed, 19 Jan 2011 03:29:25 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 613003A6ECD for ; Wed, 19 Jan 2011 03:29:25 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF900DJQPDG0Q@usaga01-in.huawei.com> for roll@ietf.org; Wed, 19 Jan 2011 03:32:04 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF9002Z5PDC0O@usaga01-in.huawei.com> for roll@ietf.org; Wed, 19 Jan 2011 03:32:03 -0800 (PST) Date: Wed, 19 Jan 2011 11:31:59 +0000 From: Adrian Farrel In-reply-to: <028501cbb646$af727170$0e575450$@com> To: 'amit dvir' Message-id: <06ac01cbb7cc$7deaeab0$79c0c010$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: multipart/alternative; boundary="Boundary_(ID_WEw3UJcwRpLwEYsyyLee2Q)" Content-language: en-gb Thread-index: AQI8RohZtN5EZmA08juIK5IWN7iafpL3C06Q References: <028501cbb646$af727170$0e575450$@com> Cc: roll@ietf.org Subject: Re: [Roll] Security extensions to RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.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, 19 Jan 2011 11:29:27 -0000 This is a multipart message in MIME format. --Boundary_(ID_WEw3UJcwRpLwEYsyyLee2Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Amit, Thanks for the work and for sharing it with the working group. draft-ietf-roll-security-framework is currently under IESG review scheduled to complete Thursday afternoon (Europe). It would be very valuable to hear whether your work uncovered any issues with that framework. Thanks, Adrian From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of amit dvir Sent: 17 January 2011 13:02 To: roll@ietf.org Subject: [Roll] Security extensions to RPL Hello, Let me kindly inform you that in an EU funded research project on dependable sensor networks (www.wsan4cip.eu), we adopted RPL as the routing protocol in our protocol stack for demonstrators, and we designed some security extensions to RPL (not yet covered by the current RPL security features). Our intention is to submit these extensions as an Internet Draft to the ROLL Working Group. The New Internet-Draft is available from the on-line Internet-Drafts directories: https://datatracker.ietf.org/doc/draft-dvir-roll-security-extensions/ We would be happy to receive comments related to this work. We also would like to mention that we are developing an implementation of RPL both in a TinyOS and in a Linux environment. We plan to make our implementation including the security extensions we specified in the New Internet-Draft available to the community later this year. Best regards, Dr. Amit Dvir Crypto and System Security Lab (CrySyS) Budapest University of Technology www.crysys.hu --Boundary_(ID_WEw3UJcwRpLwEYsyyLee2Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Amit,

 

Thanks for the work and for sharing it with the working group.

draft-ietf-roll-security-framework is currently under IESG review scheduled to complete Thursday afternoon (Europe).

It would be very valuable to hear whether your work uncovered any issues with that framework.

 

Thanks,

Adrian

 

From: roll-bounces@ietf.org [mailto b>On Behalf Of amit dvir
Sent: 17 January 2011 13:02
To: roll@ietf.org
Subject: [Roll] Security extensions to RPL

 

Hello,

 

Let me kindly inform you that in an EU funded research project on dependable sensor networks (www.wsan4cip.eu), we adopted RPL as the routing protocol in our protocol stack for demonstrators, and we designed some secur ity exte covered by the current RPL security features).

 

Our intention is to submit these extensions as an Internet Draft to the ROLL Working Group. The New Internet-Draft is available from the on-line Internet-Drafts directories:

 

ht tps://da aft-dvir-roll-security-extensions/

 

 

We would be happy to receive comments related to this work.

 

We also would like to mention that we are developing an implementation of RPL b Linux environment. We plan to make our implementation including the security extensions we specified in the New Internet-Draft available to the community later this year.

 

 

Best regards,

& nbsp;Dr. Amit Dvir

Crypto and System Security Lab (CrySyS)

Budapest University of Technology

www.crysys.hu

 

--Boundary_(ID_WEw3UJcwRpLwEYsyyLee2Q)-- From daniel@olddog.co.uk Thu Jan 20 03:27:50 2011 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 1D4F83A7219 for ; Thu, 20 Jan 2011 03:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.28 X-Spam-Level: X-Spam-Status: No, score=-102.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, 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 g45tN5YahfA2 for ; Thu, 20 Jan 2011 03:27:49 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 2E4BC3A721A for ; Thu, 20 Jan 2011 03:27:48 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p0KBUPve012657 for ; Thu, 20 Jan 2011 11:30:26 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p0KBUPAY012652 for ; Thu, 20 Jan 2011 11:30:25 GMT From: "Daniel King" To: Date: Thu, 20 Jan 2011 11:30:22 -0000 Message-ID: <00d201cbb895$6d036cd0$470a4670$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acu4lVuGgJSAmt42Q+6HfvBvNoOx3g== Content-Language: en-gb Subject: [Roll] Minutes for ROLL Interim Session Dec 20, 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: Thu, 20 Jan 2011 11:27:50 -0000 Hi All, Please find the minutes and slides for last month's interim session: http://trac.tools.ietf.org/wg/roll/trac/wiki/InterimMeeting If you have any comments on the minutes please email the chairs and myself. Br, Dan. From jpv@cisco.com Thu Jan 20 08:06:03 2011 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 A37483A7133 for ; Thu, 20 Jan 2011 08:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.444 X-Spam-Level: X-Spam-Status: No, score=-110.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 KGd2yceSWBh4 for ; Thu, 20 Jan 2011 08:06:02 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A53FA3A70F5 for ; Thu, 20 Jan 2011 08:06:02 -0800 (PST) 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: AmwEAOvsN02Q/khLgWdsb2JhbACkURUBARYiJKNKmxmFUASLHoMkBg Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 20 Jan 2011 16:08:45 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0KG8jlO031778; Thu, 20 Jan 2011 16:08:45 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 17:08:44 +0100 Received: from [192.168.0.194] ([10.55.92.19]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 17:08:43 +0100 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jan 2011 17:08:36 +0100 Message-Id: To: ROLL WG , Daniel King Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 20 Jan 2011 16:08:43.0969 (UTC) FILETIME=[4FA3D310:01CBB8BC] Cc: Adrian Farrel , David Culler Subject: [Roll] Welcome to Dan King as ROLL Secretary 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 Jan 2011 16:06:03 -0000 Dear all, I would like to warmly thank Dan King who accepted the position of ROLL = Secretary: http://datatracker.ietf.org/wg/roll/charter/=20 If you know Dan, who know how smart and efficient he is ... if you do = not know him yet you will quickly figure this out. Thanks Dan. JP.= From yoav@yitran.com Mon Jan 24 12:35:15 2011 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 28D993A692C for ; Mon, 24 Jan 2011 12:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 F2EzpDcygcoi for ; Mon, 24 Jan 2011 12:35:13 -0800 (PST) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with SMTP id 291EA3A6918 for ; Mon, 24 Jan 2011 12:35:13 -0800 (PST) Received: from source ([209.85.215.51]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTT3jMAJJy43u6zkIE1mpCJsZcKCieuQr@postini.com; Mon, 24 Jan 2011 12:38:09 PST Received: by ewy19 with SMTP id 19so2279921ewy.24 for ; Mon, 24 Jan 2011 12:38:07 -0800 (PST) Received: by 10.223.83.144 with SMTP id f16mr1669188fal.4.1295901487033; Mon, 24 Jan 2011 12:38:07 -0800 (PST) From: Yoav Ben-Yehezkel References: <028501cbb646$af727170$0e575450$@com> In-Reply-To: <028501cbb646$af727170$0e575450$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu2RqnjKD+I/WciSHWTnRV3JfvieQFvoSAg Date: Mon, 24 Jan 2011 22:36:19 +0200 Message-ID: <6f8c73a9b8328b369d7c0b1d88770f9d@mail.gmail.com> To: amit dvir , roll@ietf.org Content-Type: multipart/alternative; boundary=20cf3054a737cc6e1e049a9d9373 Subject: Re: [Roll] Security extensions to 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, 24 Jan 2011 20:35:15 -0000 --20cf3054a737cc6e1e049a9d9373 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Amit and WG, Thanks for the work you=92ve put into this ID and for sharing this draft with the group. I would like to probe the WG opinion on splitting this draft into two separate IDs, one about DIO Message Authentication and the other about Local Key Agreement. As it stands, a draft called =93security extensions to RPL=94 seems too gen= eral to understand what this draft is trying to accomplish (as there can be many more security extensions to RPL than the ones mentioned in this draft). Also, I have a feeling that the two extensions that are detailed in the draft are not so related, which one might expect from a single document describing two (out of N possible) extensions. Any thoughts from other members? Best regards, Yoav *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of *amit dvir *Sent:* Monday, January 17, 2011 3:02 PM *To:* roll@ietf.org *Subject:* [Roll] Security extensions to RPL Hello, Let me kindly inform you that in an EU funded research project on dependabl= e sensor networks (www.wsan4cip.eu), we adopted RPL as the routing protocol i= n our protocol stack for demonstrators, and we designed some security extensions to RPL (*not yet covered by the current RPL security features*). Our intention is to submit these extensions as an Internet Draft to the ROL= L Working Group. *The New Internet-Draft is available* from the on-line Internet-Drafts directories: https://datatracker.ietf.org/doc/draft-dvir-roll-security-extensions/ We would be happy to receive comments related to this work. We also would like to mention that we are developing an implementation of RPL both in a TinyOS and in a Linux environment. We plan to make our implementation including the security extensions we specified in the *New Internet-Draft *available to the community later this year. Best regards, Dr. Amit Dvir Crypto and System Security Lab (CrySyS) Budapest University of Technology www.crysys.hu --20cf3054a737cc6e1e049a9d9373 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi Amit and WG,

=A0

Thanks for the work you=92ve put into this ID and for sharin=
g this draft with the group.
=A0
I would like to probe the WG opinion on splitting this draft=
 into two separate IDs, one about DIO Message Authentication and the other =
about Local Key Agreement.

=A0

As it stands, a draft= called =93security extensions to RPL=94 seems too general to understand what this draft is try= ing to accomplish (as there can be many more security extensions to RPL than the o= nes mentioned in this draft). Also, I have a feeling that the two extensions th= at are detailed in the draft are not so related, which one might expect from a single document describing two (out of N possible) extensions.

=A0

Any thoughts from oth= er members?

=A0

Best regards,<= /p>

Yoav

=A0

=A0

From: roll-bounces@ietf.org [mailto:= roll-bounces@ietf.org] On B= ehalf Of amit dvir
Sent: Monday, January 17, 2011 3:02 PM
To: roll@ietf.org
Subject: [Roll] Security extensions to RPL

=A0

Hello,

=A0

Let me kindly inform you that in an EU funded research project on dependable se= nsor networks (www.wsan4cip.eu), we adopt= ed RPL as the routing protocol in our protocol stack for demonstrators, and we designed some security extensions = to RPL (not yet covered by the current RPL security features).

=A0

Our intention is to submit these extensions as an Internet Draft to the ROLL Working Group. The New Internet-Draft is available from the on-line Internet-Drafts directories:

=A0

https://datatracker.ietf.org/doc/draft-dvir-roll-security-= extensions/

=A0

=A0

We would be happy to receive comments related to this work.

=A0

We also would like to mention that we are developing an implementation of RPL = both in a TinyOS and in a Linux environment. We plan to make our implementation including the security extensions we specified in the New Internet-Draft= available to the community later this year.

=A0

=A0

Best regards,

=A0

Dr. Amit Dvir

Crypto and System Security Lab (CrySyS)

Budapest University of Technology

www.crysys.hu

=A0

--20cf3054a737cc6e1e049a9d9373-- From ulrich@herberg.name Thu Jan 27 01:17:19 2011 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 DACDF28C10E for ; Thu, 27 Jan 2011 01:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 DLTmDLre8jel for ; Thu, 27 Jan 2011 01:17:17 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 95B9528C12B for ; Thu, 27 Jan 2011 01:17:16 -0800 (PST) Received: by qwi2 with SMTP id 2so2008554qwi.31 for ; Thu, 27 Jan 2011 01:20:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.89.69 with SMTP id d5mr1527243qam.59.1296120018850; Thu, 27 Jan 2011 01:20:18 -0800 (PST) Received: by 10.220.182.193 with HTTP; Thu, 27 Jan 2011 01:20:18 -0800 (PST) Date: Thu, 27 Jan 2011 10:20:18 +0100 Message-ID: From: Ulrich Herberg To: roll WG Content-Type: multipart/alternative; boundary=0015175cb6f24f52ca049ad07536 Subject: [Roll] Local repair 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 Jan 2011 09:17:19 -0000 --0015175cb6f24f52ca049ad07536 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have some questions about the local repair mechanism, in particular the poisoning mechanism. How exactly would the mechanism work? As said in the spec, there is a risk that a node's sub-DODAG does not receive the DIOs that advertise a rank of INIFINITY, and thus the node may attach to its sub-DODAG (and thus causing loops). Would it make sense for a node, that starts poisoning, to wait for a certain time before parsing any DIOs? That could increase the chance that any of the poisoned DIOs are received by the children of the node. Not only could the poisoned DIOs be lost, it could also happen that one child happens to submit its DIO first, even before the poisoned DIO is sent. Another question: When a node starts poisoning, will it reset somehow its state, i.e. remove part of the neighbor set, start sending DIS messages, etc? What happens if the node cannot attach to any parent (because there is none) and does not create a floating DODAG? Will it send the poisoned DIOs forever, or will it stop sending them after some number of DIOs? A question about DIS messages. There is a difference how multicast and unicast DIS messages are treated. In my Java-based implementation (used for simulations), I cannot discern whether an incoming packet is multicast or unicast (there are no raw sockets in Java, and no access to the IP header). Of course, one may say that Java is not typically used for real implementations (and I agree), but there might be other operating systems or programming languages that make it difficult to access any information other than the payload of a packet. Adding a single bit in the flags field would help to easily decide whether an incoming DIS should reset the trickle timer or not, without inspection of the IP header. I still hope that my questions about the DAO/DAOACK mechanism (email from January 12) would be answered by someone... :-) Thanks Ulrich --0015175cb6f24f52ca049ad07536 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I have some questions about the local repair mechanism, in parti= cular the poisoning mechanism. How exactly would the mechanism work? As sai= d in the spec, there is a risk that a node's sub-DODAG does not receive= the DIOs that advertise a rank of INIFINITY, and thus the node may attach = to its sub-DODAG (and thus causing loops). Would it make sense for a node, = that starts poisoning, to wait for a certain time before parsing any DIOs? = That could increase the chance that any of the poisoned DIOs are received b= y the children of the node. Not only could the poisoned DIOs be lost, it co= uld also happen that one child happens to submit its DIO first, even before= the poisoned DIO is sent.
Another question: When a node starts poisoning, will it reset somehow its s= tate, i.e. remove part of the neighbor set, start sending DIS messages, etc= ? What happens if the node cannot attach to any parent (because there is no= ne) and does not create a floating DODAG? Will it send the poisoned DIOs fo= rever, or will it stop sending them after some number of DIOs?

A question about DIS messages. There is a difference how multicast and = unicast DIS messages are treated. In my Java-based implementation (used for= simulations), I cannot discern whether an incoming packet is multicast or = unicast (there are no raw sockets in Java, and no access to the IP header).= Of course, one may say that Java is not typically used for real implementa= tions (and I agree), but there might be other operating systems or programm= ing languages that make it difficult to access any information other than t= he payload of a packet. Adding a single bit in the flags field would help t= o easily decide whether an incoming DIS should reset the trickle timer or n= ot, without inspection of the IP header.

I still hope that my questions about the DAO/DAOACK mechanism (email fr= om January 12) would be answered by someone... :-)

Thanks
Ulrich<= br> --0015175cb6f24f52ca049ad07536-- From mounir.kellil@cea.fr Thu Jan 27 08:27:13 2011 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 A0CF23A690A for ; Thu, 27 Jan 2011 08:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 380B40v4r0LH for ; Thu, 27 Jan 2011 08:27:10 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 2294A3A6903 for ; Thu, 27 Jan 2011 08:27:09 -0800 (PST) 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 p0RGUCnE014566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 27 Jan 2011 17:30:12 +0100 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 p0RGUC2U014410 for ; Thu, 27 Jan 2011 17:30:12 +0100 (envelope-from mounir.kellil@cea.fr) Received: from levau.intra.cea.fr (levau.intra.cea.fr [132.166.88.52]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p0RGUCcd014203 for ; Thu, 27 Jan 2011 17:30:12 +0100 Received: from LODERI.intra.cea.fr ([132.166.64.44]) by levau.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jan 2011 17:30:12 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBE3F.783900D6" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 27 Jan 2011 17:30:10 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Question about RPL and multicast thread-index: Acu+A3/TqkwGsqLuRKaoEyB6LUfOTgAOhYHg References: From: "KELLIL Mounir" To: "roll WG" X-OriginalArrivalTime: 27 Jan 2011 16:30:12.0104 (UTC) FILETIME=[7851E080:01CBBE3F] Subject: [Roll] Question about RPL and multicast 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 Jan 2011 16:27:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBE3F.783900D6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 In the last version of RPL draft, it is mentioned that an RPL node (a router) forwards multicast data to the preferred parents and to the children that have subscribed to the multicast group. Yet, it is not clear whether this packet forwarding is achieved through IP tunnelling (multicast-in-unicast) or using L2 (unicast) relaying? (I'd say the second is right, but I'm not sure). And, the same question arises for the case of the multicast source within the DODAG.. =20 Best regards =20 Mounir ------_=_NextPart_001_01CBBE3F.783900D6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = all,

 

In the last = version of RPL draft, it is mentioned that an RPL node (a router) forwards = multicast data to the preferred parents and to the children that have subscribed to the multicast group. Yet, it is not clear whether this packet forwarding is = achieved through IP tunnelling (multicast-in-unicast) or using L2 (unicast) = relaying? (I’d say the second is right, but I’m not sure). And, the same question = arises for the case of the multicast source within the = DODAG..

 =

Best = regards

 

Mounir

------_=_NextPart_001_01CBBE3F.783900D6-- From pal@cs.stanford.edu Thu Jan 27 09:26:21 2011 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 2E3E63A696F for ; Thu, 27 Jan 2011 09:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 gXQjg2Z7lhWd for ; Thu, 27 Jan 2011 09:26:19 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 7BDF93A696E for ; Thu, 27 Jan 2011 09:26:19 -0800 (PST) Received: from dn0a210222.sunet ([10.33.2.34]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PiVet-0005ap-3C; Thu, 27 Jan 2011 09:29:23 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Thu, 27 Jan 2011 09:29:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <13A9A72D-36B2-453C-B5B4-D93F69C14BAE@cs.stanford.edu> References: To: Ulrich Herberg X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 323acaff36744e8473855e70acc36bcb Cc: roll WG Subject: Re: [Roll] Local repair 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 Jan 2011 17:26:21 -0000 On Jan 27, 2011, at 1:20 AM, Ulrich Herberg wrote: > Hi, >=20 > I have some questions about the local repair mechanism, in particular = the poisoning mechanism. How exactly would the mechanism work? As said = in the spec, there is a risk that a node's sub-DODAG does not receive = the DIOs that advertise a rank of INIFINITY, and thus the node may = attach to its sub-DODAG (and thus causing loops). Would it make sense = for a node, that starts poisoning, to wait for a certain time before = parsing any DIOs? That could increase the chance that any of the = poisoned DIOs are received by the children of the node. Not only could = the poisoned DIOs be lost, it could also happen that one child happens = to submit its DIO first, even before the poisoned DIO is sent.=20 Think of what the cost here: you're preventing a node from having a = route in order to prevent the possible creation of a loop. But you can = detect and repair a loop immediately, so what's the harm? I realize it's = a bit weird to wrap your head around, but take a look at the CTP paper. = If you have datapath validation, you don't need to poison (CTP doesn't). = The only one danger is the count-to-infinity problem, but poisoning will = only reduce, not solve, that problem due to the lossy nature of LLNs. = That's why there the configuration option for max rank increase within = an iteration. > Another question: When a node starts poisoning, will it reset somehow = its state, i.e. remove part of the neighbor set, start sending DIS = messages, etc? What happens if the node cannot attach to any parent = (because there is none) and does not create a floating DODAG? Will it = send the poisoned DIOs forever, or will it stop sending them after some = number of DIOs? No. Removing part of your neighbor set could be a disastrously expensive = decision (a node has spent a good deal of effort to build up link and = route estimates). If the poisoning spreads correctly, then neighbors = which are in the sub-DODAG and have no other routes available will = advertise a rank of infinity. Note that this process may be very slow, = as nodes in the sub-DODAG select each other as preferred parents and = detect loops. > A question about DIS messages. There is a difference how multicast and = unicast DIS messages are treated. In my Java-based implementation (used = for simulations), I cannot discern whether an incoming packet is = multicast or unicast (there are no raw sockets in Java, and no access to = the IP header). Of course, one may say that Java is not typically used = for real implementations (and I agree), but there might be other = operating systems or programming languages that make it difficult to = access any information other than the payload of a packet. Adding a = single bit in the flags field would help to easily decide whether an = incoming DIS should reset the trickle timer or not, without inspection = of the IP header. I am not 100% up-to-date on the Java API, but can't you create two = sockets, one for the global unicast address and one for the link-local = multicast address? If Java doesn't give you raw sockets, how do you send = DIS/DIO/etc. messages? Maybe you could sketch things out a bit better. The argument for putting this bit in the DIS has come up before; the = issue that arises is when an implementation sends a DIS with the bit = configured to not reset the trickle timer, but does so to a multicast = address. There will be DIO implosion as a result. Phil From ulrich@herberg.name Fri Jan 28 05:25:35 2011 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 6E5E73A686E for ; Fri, 28 Jan 2011 05:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 LAWo0YhMsghH for ; Fri, 28 Jan 2011 05:25:34 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id B59083A67AD for ; Fri, 28 Jan 2011 05:25:33 -0800 (PST) Received: by qyj19 with SMTP id 19so3461747qyj.10 for ; Fri, 28 Jan 2011 05:28:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.6.144 with SMTP id 16mr3016429qaz.159.1296221319370; Fri, 28 Jan 2011 05:28:39 -0800 (PST) Received: by 10.220.182.193 with HTTP; Fri, 28 Jan 2011 05:28:39 -0800 (PST) In-Reply-To: <13A9A72D-36B2-453C-B5B4-D93F69C14BAE@cs.stanford.edu> References: <13A9A72D-36B2-453C-B5B4-D93F69C14BAE@cs.stanford.edu> Date: Fri, 28 Jan 2011 14:28:39 +0100 Message-ID: From: Ulrich Herberg To: Philip Levis Content-Type: multipart/alternative; boundary=0015175cb05e4a9797049ae80b78 Cc: roll WG Subject: Re: [Roll] Local repair 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 Jan 2011 13:25:35 -0000 --0015175cb05e4a9797049ae80b78 Content-Type: text/plain; charset=ISO-8859-1 Philip, On Thu, Jan 27, 2011 at 6:29 PM, Philip Levis wrote: > > On Jan 27, 2011, at 1:20 AM, Ulrich Herberg wrote: > > > Hi, > > > > I have some questions about the local repair mechanism, in particular the > poisoning mechanism. How exactly would the mechanism work? As said in the > spec, there is a risk that a node's sub-DODAG does not receive the DIOs that > advertise a rank of INIFINITY, and thus the node may attach to its sub-DODAG > (and thus causing loops). Would it make sense for a node, that starts > poisoning, to wait for a certain time before parsing any DIOs? That could > increase the chance that any of the poisoned DIOs are received by the > children of the node. Not only could the poisoned DIOs be lost, it could > also happen that one child happens to submit its DIO first, even before the > poisoned DIO is sent. > > Think of what the cost here: you're preventing a node from having a route > in order to prevent the possible creation of a loop. But you can detect and > repair a loop immediately, so what's the harm? I mostly agree, but there is some cost: First, the data packet would be delayed if for each data packet loop freeness is tested, and possibly routes repaired. That may be tolerable for some applications (collection of data from sensors, such as temperature), but for other applications (home automation: light switch) that may be less tolerable. Also, that would require a mixture of data plane and control plane, since for each data packet, the routing protocol has to be notified about the direction of the packet, and verify the rank of the previous hop. If this datapath loop correction is executed for each data packet, that process may also cost more energy than having some more clever repair mechanism now and then. So, while I agree that it may be easier to fix loops when data packets arrive, I claim that it is not for "free". Maybe such a description of the tradeoff could be added to the RPL spec? > I realize it's a bit weird to wrap your head around, but take a look at the > CTP paper. Could you please send me a reference? > If you have datapath validation, you don't need to poison (CTP doesn't). If we don't need to poison, why is it specified in RPL then? > The only one danger is the count-to-infinity problem, but poisoning will > only reduce, not solve, that problem due to the lossy nature of LLNs. That's > why there the configuration option for max rank increase within an > iteration. > I agree. > > > Another question: When a node starts poisoning, will it reset somehow its > state, i.e. remove part of the neighbor set, start sending DIS messages, > etc? What happens if the node cannot attach to any parent (because there is > none) and does not create a floating DODAG? Will it send the poisoned DIOs > forever, or will it stop sending them after some number of DIOs? > > No. Removing part of your neighbor set could be a disastrously expensive > decision (a node has spent a good deal of effort to build up link and route > estimates). Yes, I assumed that. I had spoken with a colleague who is working with the ContikiRPL implementation. They are throwing away the information about all parents, if a loop between a router and one of its parents is detected. That's why I asked, but I assume it would be better to just throw away the one parent where the loop has been detected. > If the poisoning spreads correctly, then neighbors which are in the > sub-DODAG and have no other routes available will advertise a rank of > infinity. Note that this process may be very slow, as nodes in the sub-DODAG > select each other as preferred parents and detect loops. > Yes. > > > > A question about DIS messages. There is a difference how multicast and > unicast DIS messages are treated. In my Java-based implementation (used for > simulations), I cannot discern whether an incoming packet is multicast or > unicast (there are no raw sockets in Java, and no access to the IP header). > Of course, one may say that Java is not typically used for real > implementations (and I agree), but there might be other operating systems or > programming languages that make it difficult to access any information other > than the payload of a packet. Adding a single bit in the flags field would > help to easily decide whether an incoming DIS should reset the trickle timer > or not, without inspection of the IP header. > > I am not 100% up-to-date on the Java API, but can't you create two sockets, > one for the global unicast address and one for the link-local multicast > address? Yes, you are fully right... I was not thinking about that. Stupid me... ;-) > If Java doesn't give you raw sockets, how do you send DIS/DIO/etc. > messages? Maybe you could sketch things out a bit better. > I encapsulate the payload in UDP, since to my knowledge Java cannot send ICMPv6 messages, unless some native code is used (e.g. using jpcap). > > The argument for putting this bit in the DIS has come up before; the issue > that arises is when an implementation sends a DIS with the bit configured to > not reset the trickle timer, but does so to a multicast address. There will > be DIO implosion as a result. > Okay, I see. Thanks Ulrich --0015175cb05e4a9797049ae80b78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Philip,

On Thu, Jan 27, 2011 at 6:29 PM, = Philip Levis <pal@cs.stanford.edu> wrote:

On Jan 27, 2011, at 1:20 AM, Ulrich Herberg wrote:

> Hi,
>
> I have some questions about the local repair mechanism, in particular = the poisoning mechanism. How exactly would the mechanism work? As said in t= he spec, there is a risk that a node's sub-DODAG does not receive the D= IOs that advertise a rank of INIFINITY, and thus the node may attach to its= sub-DODAG (and thus causing loops). Would it make sense for a node, that s= tarts poisoning, to wait for a certain time before parsing any DIOs? That c= ould increase the chance that any of the poisoned DIOs are received by the = children of the node. Not only could the poisoned DIOs be lost, it could al= so happen that one child happens to submit its DIO first, even before the p= oisoned DIO is sent.

Think of what the cost here: you're preventing a node from having= a route in order to prevent the possible creation of a loop. But you can d= etect and repair a loop immediately, so what's the harm?


I mostly agree, but there is some cost: First, the data packet= would be delayed if for each data packet loop freeness is tested, and poss= ibly routes repaired. That may be tolerable for some applications (collecti= on of data from sensors, such as temperature), but for other applications (= home automation: light switch) that may be less tolerable. Also, that would= require a mixture of data plane and control plane, since for each data pac= ket, the routing protocol has to be notified about the direction of the pac= ket, and verify the rank of the previous hop. If this datapath loop correct= ion is executed for each data packet, that process may also cost more energ= y than having some more clever repair mechanism now and then.
So, while I agree that it may be easier to fix loops when data packets arri= ve, I claim that it is not for "free". Maybe such a description o= f the tradeoff could be added to the RPL spec?


=A0
I realize it's a bit weird to wrap your head around, but take a look at= the CTP paper.

Could you please send me a reference?=

=A0
If you have datapath validation, you don't need to poison (CTP doesn= 9;t).

If we don't need to poison, why is it speci= fied in RPL then?

=A0
The only one danger is the count-to-infinity problem, but poisoning will on= ly reduce, not solve, that problem due to the lossy nature of LLNs. That= 9;s why there the configuration option for max rank increase within an iter= ation.

I agree.
=A0

> Another question: When a node starts poisoning, will it reset somehow = its state, i.e. remove part of the neighbor set, start sending DIS messages= , etc? What happens if the node cannot attach to any parent (because there = is none) and does not create a floating DODAG? Will it send the poisoned DI= Os forever, or will it stop sending them after some number of DIOs?

No. Removing part of your neighbor set could be a disastrously expens= ive decision (a node has spent a good deal of effort to build up link and r= oute estimates).

Yes, I assumed that. I had spoken wit= h a colleague who is working with the ContikiRPL implementation. They are t= hrowing away the information about all parents, if a loop between a router = and one of its parents is detected. That's why I asked, but I assume it= would be better to just throw away the one parent where the loop has been = detected.


=A0
= If the poisoning spreads correctly, then neighbors which are in the sub-DO= DAG and have no other routes available will advertise a rank of infinity. N= ote that this process may be very slow, as nodes in the sub-DODAG select ea= ch other as preferred parents and detect loops.

Yes.
=A0


> A question about DIS messages. There is a difference how multicast and= unicast DIS messages are treated. In my Java-based implementation (used fo= r simulations), I cannot discern whether an incoming packet is multicast or= unicast (there are no raw sockets in Java, and no access to the IP header)= . Of course, one may say that Java is not typically used for real implement= ations (and I agree), but there might be other operating systems or program= ming languages that make it difficult to access any information other than = the payload of a packet. Adding a single bit in the flags field would help = to easily decide whether an incoming DIS should reset the trickle timer or = not, without inspection of the IP header.

I am not 100% up-to-date on the Java API, but can't you create tw= o sockets, one for the global unicast address and one for the link-local mu= lticast address?

Yes, you are fully right... I was not= thinking about that. Stupid me... ;-)


=A0
If Java= doesn't give you raw sockets, how do you send DIS/DIO/etc. messages? M= aybe you could sketch things out a bit better.

I encapsulate the payload in UDP, since to my knowled= ge Java cannot send ICMPv6 messages, unless some native code is used (e.g. = using jpcap).
=A0

The argument for putting this bit in the DIS has come up before; the issue = that arises is when an implementation sends a DIS with the bit configured t= o not reset the trickle timer, but does so to a multicast address. There wi= ll be DIO implosion as a result.

Okay, I see.

Thanks
Ulrich

--0015175cb05e4a9797049ae80b78-- From pal@cs.stanford.edu Fri Jan 28 09:18:18 2011 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 041413A67B0 for ; Fri, 28 Jan 2011 09:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NcyVMXtkmbyB for ; Fri, 28 Jan 2011 09:18:16 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id CB0AA3A68E9 for ; Fri, 28 Jan 2011 09:18:16 -0800 (PST) Received: from [76.14.66.110] (helo=[192.168.0.100]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Pis0h-0005co-6x; Fri, 28 Jan 2011 09:21:23 -0800 In-Reply-To: References: <13A9A72D-36B2-453C-B5B4-D93F69C14BAE@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37DC74FB-1E2A-41C7-AD1B-07B8D4294E55@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Fri, 28 Jan 2011 09:21:22 -0800 To: Ulrich Herberg X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 0858a923cc4ba3562bb802375c61c59b Cc: roll WG Subject: Re: [Roll] Local repair 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 Jan 2011 17:18:18 -0000 On Jan 28, 2011, at 5:28 AM, Ulrich Herberg wrote: > Philip, > > On Thu, Jan 27, 2011 at 6:29 PM, Philip Levis > wrote: > > On Jan 27, 2011, at 1:20 AM, Ulrich Herberg wrote: > > > Hi, > > > > I have some questions about the local repair mechanism, in > particular the poisoning mechanism. How exactly would the mechanism > work? As said in the spec, there is a risk that a node's sub-DODAG > does not receive the DIOs that advertise a rank of INIFINITY, and > thus the node may attach to its sub-DODAG (and thus causing loops). > Would it make sense for a node, that starts poisoning, to wait for > a certain time before parsing any DIOs? That could increase the > chance that any of the poisoned DIOs are received by the children > of the node. Not only could the poisoned DIOs be lost, it could > also happen that one child happens to submit its DIO first, even > before the poisoned DIO is sent. > > Think of what the cost here: you're preventing a node from having a > route in order to prevent the possible creation of a loop. But you > can detect and repair a loop immediately, so what's the harm? > > > I mostly agree, but there is some cost: First, the data packet > would be delayed if for each data packet loop freeness is tested, > and possibly routes repaired. That may be tolerable for some > applications (collection of data from sensors, such as > temperature), but for other applications (home automation: light > switch) that may be less tolerable. Also, that would require a > mixture of data plane and control plane, since for each data > packet, the routing protocol has to be notified about the direction > of the packet, and verify the rank of the previous hop. If this > datapath loop correction is executed for each data packet, that > process may also cost more energy than having some more clever > repair mechanism now and then. Generally, no -- the cost of executing a few instructions is inconsequential in comparison to sending a packet (generally by > 6 orders of magnitude). The energy costs of any not ridiculous (solve equations on each packet) packet processing are typically irrelevant in LLNs. We can start exploring really hypothetical points in the energy/capability space, but there's no evidence I've seen that such a point might ever appear, and it's probably useful to instead focus on more pressing concerns. > So, while I agree that it may be easier to fix loops when data > packets arrive, I claim that it is not for "free". Maybe such a > description of the tradeoff could be added to the RPL spec? It's been studied. Take a look at the CTP paper below. > Could you please send me a reference? > http://sing.stanford.edu/gnawali/ctp/ and the paper: http://sing.stanford.edu/gnawali/ctp/sensys09-ctp.pdf > > Yes, I assumed that. I had spoken with a colleague who is working > with the ContikiRPL implementation. They are throwing away the > information about all parents, if a loop between a router and one > of its parents is detected. That's why I asked, but I assume it > would be better to just throw away the one parent where the loop > has been detected. This is a terrible idea -- you should instead just mark the parent's new Rank/Metrics etc. Whether or not the parent is evicted from the neighbor table should be independent of whether its change is due to a possible loop. E.g., it could be that the parent is currently looping through this node, but after loops are repaired this node will need to route through that neighbor (which chooses a different route). Phil From ulrich@herberg.name Fri Jan 28 09:36:48 2011 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 24FA43A68EF for ; Fri, 28 Jan 2011 09:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 2vBPGeg6uun2 for ; Fri, 28 Jan 2011 09:36:46 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id C733A3A68E3 for ; Fri, 28 Jan 2011 09:36:46 -0800 (PST) Received: by qwi2 with SMTP id 2so3747583qwi.31 for ; Fri, 28 Jan 2011 09:39:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.6.144 with SMTP id 16mr3224006qaz.159.1296236393106; Fri, 28 Jan 2011 09:39:53 -0800 (PST) Received: by 10.220.182.193 with HTTP; Fri, 28 Jan 2011 09:39:52 -0800 (PST) In-Reply-To: <37DC74FB-1E2A-41C7-AD1B-07B8D4294E55@cs.stanford.edu> References: <13A9A72D-36B2-453C-B5B4-D93F69C14BAE@cs.stanford.edu> <37DC74FB-1E2A-41C7-AD1B-07B8D4294E55@cs.stanford.edu> Date: Fri, 28 Jan 2011 18:39:52 +0100 Message-ID: From: Ulrich Herberg To: Philip Levis Content-Type: multipart/alternative; boundary=0015175cb05ec18bff049aeb8d1e Cc: roll WG Subject: Re: [Roll] Local repair 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 Jan 2011 17:36:48 -0000 --0015175cb05ec18bff049aeb8d1e Content-Type: text/plain; charset=ISO-8859-1 Phil, On Fri, Jan 28, 2011 at 6:21 PM, Philip Levis wrote: > > > Could you please send me a reference? >> >> > http://sing.stanford.edu/gnawali/ctp/ > > and the paper: > > http://sing.stanford.edu/gnawali/ctp/sensys09-ctp.pdf Thanks. > > Yes, I assumed that. I had spoken with a colleague who is working with the >> ContikiRPL implementation. They are throwing away the information about all >> parents, if a loop between a router and one of its parents is detected. >> That's why I asked, but I assume it would be better to just throw away the >> one parent where the loop has been detected. >> > > This is a terrible idea -- you should instead just mark the parent's new > Rank/Metrics etc. Whether or not the parent is evicted from the neighbor > table should be independent of whether its change is due to a possible loop. > E.g., it could be that the parent is currently looping through this node, > but after loops are repaired this node will need to route through that > neighbor (which chooses a different route). > I agree with you. What I wonder is whether this shouldn't be a bit explained in the RPL spec (e.g. in sections like "Local Repair Mechanism" / "Poisoning a sub-DODAG", that explain what an implementation should do, and what it should not do) . The fact that implementations do the local repair wrongly, may indicate that it is not always clear for implementers. Ulrich --0015175cb05ec18bff049aeb8d1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Phil,

On Fri, Jan 28, 2011 at 6:21 PM, Ph= ilip Levis <pal= @cs.stanford.edu> wrote:


Could you please send me a reference?


h= ttp://sing.stanford.edu/gnawali/ctp/

and the paper:

http://sing.stanford.edu/gnawali/ctp/sensys09-ctp.pdf


Thanks.
=A0

Yes, I assumed that. I had spoken with a colleague who is working with the = ContikiRPL implementation. They are throwing away the information about all= parents, if a loop between a router and one of its parents is detected. Th= at's why I asked, but I assume it would be better to just throw away th= e one parent where the loop has been detected.

This is a terrible idea -- you should instead just mark the parent's ne= w Rank/Metrics etc. Whether or not the parent is evicted from the neighbor = table should be independent of whether its change is due to a possible loop= . E.g., it could be that the parent is currently looping through this node,= but after loops are repaired this node will need to route through that nei= ghbor (which chooses a different route).


I agree with you. What I wonder is whether this s= houldn't be a bit explained in the RPL spec (e.g. in sections like &quo= t;Local Repair Mechanism" / "Poisoning a sub-DODAG", that ex= plain what an implementation should do, and what it should not do) . The fa= ct that implementations do the local repair wrongly, may indicate that it i= s not always clear for implementers.

Ulrich
--0015175cb05ec18bff049aeb8d1e-- From Internet-Drafts@ietf.org Sun Jan 30 04:00:03 2011 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 2E8823A696E; Sun, 30 Jan 2011 04:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, 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 1KUH-kPA7D61; Sun, 30 Jan 2011 04:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44493A694A; Sun, 30 Jan 2011 04:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110130120001.31126.77239.idtracker@localhost> Date: Sun, 30 Jan 2011 04:00:01 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-17.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 Jan 2011 12:00: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 : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, et al. Filename : draft-ietf-roll-routing-metrics-17.txt Pages : 30 Date : 2011-01-30 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-17.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-routing-metrics-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-30035057.I-D@ietf.org> --NextPart--